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