Hi Margaret, My 2 cents: > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier.
It does specifically state that it is an Informational document and does not contradict existing standards. An IETF standard is a procedural issue, in my mind (following a specific route to Full Standard status). I'm not so sure what to say, unless you prefer we state something like: This document is an Informational Document, not a Standards Track document. It is not meant to modify existing Standards Track documents. (use of this document in non-standard ways may affect your warranty; city and highway mileage may differ. Offer limited, while supplies last ...) > IPv6 hosts must include a full implementation of Neighbor Discovery, > including NUD with the full ND state machine, etc. Any compromise > on this effectively results in two different types of IPv6 hosts, > each with different behaviours/failure modes, etc. That is something > that we definitely want to avoid. Do the RFCs mandate a full ND state machine? I thought that is much more of an inplementation issue. However, the text does not state anywhere that Neighbor Discovery is optional to use, but tries to indicate in what circumstances the sending of NS and NA messages can be avoided. It does not put any requirements for them not to be sent. > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. This document > should indicate that support for that feature is required. For AH you explicitly state that we need say that AH is mandatory, full stop, as it is an existing requirement. For the above, however, CN functionality is not yet standardized, not yet through a security area review, etc. Additionally, I would think that it is the IPv6 WG to decide what is a mandatory feature an IPv6 node. It would be reckless to advice implementors to implement things which are not standardized, but we can call out that the work is on going and the clever implementor would review the current status of the MIPv6 specification. When MIPv6 becomes a standard, then our document should be updated accordingly. I don't think we can do anything else. > The "should not support...unless there are no other" construct > is somewhat confusing, since there probably isn't any way for > a host to know whether there are other mechanisms available. How about: Cellular hosts should not use configured or automatic tunnels, if there are other mechanisms available to the host, in order to avoid unnecessary tunneling over the air. .... > There is an ongoing effort in the ngtrans WG to discuss transition > scenarios for 3GPP (run by Jonne Soininen), and it is expected that > that group will define what type of transition mechanisms are most >applicable to 3GPP networks. So, perhaps it is best to leave this > operator advice for that group? Sure. This document was started before the NGTRANS work had started, and we just haven't deleted the duplicate info. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
