RE : IETF References (As per my action item)
Hi Greg,
I was simply not sure the 802.21 people were used to IETF standards terminology and didn't want to loose people between "standards track", "informational" and "experimental" RFCs in such a mail. Anyway your clarification is correct!
Eric
> -----Message d'origine-----
> De : Greg Daley [mailto:greg.daley@eng.monash.edu.au]
> Envoyé : jeudi 19 août 2004 01:51
> À : NJEDJOU Eric RD-RESA-REN
> Cc : STDS-802-21@listserv.ieee.org; Gupta, Vivek G
> Objet : Re: IETF References (As per my action item)
>
>
> Hi Eric,
>
> Just to clarify a small point in your description.
>
> NJEDJOU Eric RD-RESA-REN wrote:
> > Hello ad-hoc folks,
> >
> > During the last ad-hoc conf call, i have taken the action point of
> > providing a "complete" list of Internet Drafts and RFC
> pertaining to
> > triggers. The result of my investigation is the following list that
> > indicates references to documents that are not listed in the
> > present version of the Requirements documents. This gives
> a figure of
> > 17 references (if added to the already mentionned)
> >
> > 1.Pete McCan Mobile IPv6 Fast Handovers for 802.11 Networks,
> > draft-ietf-mipshop-80211fh-01.txt, July 2004
> > 2.Daniel Soohong Park, Eric Njedjou, Nicolas Montavont, L2 Triggers
> > Optimized Mobile IPv6 Vertical Handover draft-daniel-mip6-
>
> > optimized-vertical-handover-00.txt, February 2004
> > 3.Layer-2 API for paging, Sridhar
> > Gurivireddy, draft-guri-seamoby-paging-triggers-00.txt, October 2001
> > 4.JinHyeock Choi , Fast Router Discovery with AP Notification
> > draft-jinchoi-l2trigger-fastrd-01.txt, June 2002
> > 5.Kamel Baba et al. Fast Handoff L2 Trigger API,
> > draft-singh-l2trigger-api-00.txt, September 2002
> > 6.R.J Jayabal, Context transfer and fast Mobile IPv6
> Interactions in a
> > layer-2 source triggered anticipative handover, draft-rjaya-ct-fmip6
> > -l2st-ant-ho-00.txt,
> > 7. Scott Corson, a Triggered
> > Interface, draft-corson-triggered-00.txt May November 2002
> > 8.Carl Williams, Alper E. Yegin, and James Kempf, Problem
> Statement for
> > Link-layer Triggers, draft-williams-l2-probstmt-00.txt June 2002
> >
> > *Comment 1: Internet Drafts validity*
> > As you can see, added to the already present list, we come
> up with an
> > impressive list of references. And i have restricted myself to
> > indicating only the documents that directly address the triggers
> > problem. There a dozen others talking about fast handovers, context
> > transfer...etc which some are indicated in the Req Document
> already.
> > Another point is that all of the above documents expect one
> (the first)
> > have expired and have been deleted from the internet drafts
> repository.
> > This is why the list is not exhaustive as once Internet
> Drafts have been
> > deleted, the only way to retrieve them is to search into private
> > repositories that don't provide the guarantee of
> completeness. An IETF
> > draft has a lifetime of 6 months and expires if either a
> new version is
> > not submitted within the 6 months following its publication or the
> > document has not been considered for evolution on the
> standard track.
> >
> > *Comment 2: history of triggers at IETF*
> > There are no RFCs pertaining to triggers. There is an long history
> > of attempts to standardize triggers within the IETF. But all of
> > them have failed: A first attempt to drive people attention on
> > the subject was made with the incentive of people from the
> IP mobility
> > community during the 53th IETF meeting in March 2003 in
> Minneapolis
> > where an informal BAR-BOF was held. The concern at that
> time was already
> > to try to bring a solution to the problem of latency as could be
> > experienced when running Mobile IP on certain links especially the
> > wireless ones, when indications from link layers were not
> made to MIP.
> > The BAR-BOF discussions did not lead to the set up of a Working
> > Group. Since, interest has grown, then faded again but no
> group within
> > the IETF between Seamoby, Mobile IP, has ever been willing
> to carry a
> > standardization effort. DNA has recently expressed the will
> to have a
> > catalogue of link events that could help the process of
> detecting the
> > attachment to a network.The DNA catalogue is therefore for
> a narrow use.
> > FInally MOBOPTS (sort of open forum within the IETF has
> been receiving
> > suggestions but has not mandate to standardize anything as
> it is only a
> > group from the IRTF (Research Task Force) not very active.
> > The only document currently on standard track (liable to
> become an RFC)
> > and that have a vague relation to 802.11 triggers is the
> first reference
> > in the above list from the MIPSHOP Working Group.
>
>
> Fast Handovers for 802.11 is not currently "Standards Track", as it
> relies upon "draft-ietf-mipshop-fast-mipv6-02.txt" which is aimed
> to become an "Experimental" RFC. It is therefore an "Experimental"
> RFC.
>
> Experimental RFC's are valid for proving new ideas (many TCP related
> RFCs were in wide use while still remaining 'Experimental' for a
> long time before moving to Standards Track.
>
> The maturity of the Fast Handovers proposals is fairly good, and
> there's a good chance of them making such a transition.
>
> Several Documents within the DNA working group which are aimed at
> Standards Track will make use of Link-Layer Event Notifications
> (probably synonymous with triggers) as input to configuration
> detection processes. As Eric mentioned though, these are
> mainly aimed at Link-Up/Link-Down indications at the moment, and
> are earlier in their life cycle than Fast Handovers documents.
>
> > *Comment 3: IETF wary of link stuffs*
> > The IETF has always been wary of link layers stuffs and especially
> > triggers as a network layer focused population not really
> at ease with
> > L2 things. Expectations have therefore always been to see
> such SDOs as
> > IEEE or 3GPP take into account their will to have access
> > technologies (IEEE 802.11, GPRS...) being modified in a way
> to optimize
> > the operation of the protocols they design. *therefore IMHO, those
> > expectations can not take the form of references for
> 802.21. *It would
> > have to be the other way round once 21 will have produced
> its standard* *
> >
> > *Suggestion:*
> > As a consequence of the above remarks, i would suggest *not
> listing any
> > document instead of having 17 references from individual
> submissions
> > that have expired, have no normative value (RFC) or not
> looked at by any
> > IETF Working Group to become so except the first in the
> above list. *
> > An appropriate thing would be to *request an official
> liaison with the
> > IETF* or have them produce a document (informational RFC
> for instance)
> > that capture their expectations of what 802.21 should contain to
> > satisfy the need of their layer3 mobility protocols.(Mobile
> IP, Fast
> > Handoffs, HIP...). In that way we will be sure we meet "official"
> > expectations rather than individual ones in the references we have.
> > The IETF is familiar with this process as they have already
> submitted
> > submitted such information RFCs for consideration by the 3GPP
> >
> > See you tommorrow
>
> Good Luck with the meeting.
>
> Greg Daley
>
>