Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts"

From: [email-masked]
Date: Wed, 22 May 2002 21:25:15 +0300

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 22 May 2002 21:28:43 +0300

Hi Margaret,
 
> In this case, the intended audience of the document primarily lies outside of the
> IETF.  Do you think that they will really understand the difference between our
> different document types?

I think you should give a little credit to folks - I do think they understand
the IETF document notation system.  How about if we add a reference
to where IETF documents are defined?  That would probably be enough.
 
John