Subject: RE: IPv6 w.g. Last Call on "IPv6 Node Requirements"

From: <[email-masked]>
Date: Wed, 9 Jul 2003 13:48:26 +0300

Hi all,

So far, it seems that there has been limited comments on this.  I could
assume that everyone's read it & is satisfied.  However, there is still 
plenty of time to get comments on this, so please read it.

thanks,
John

> This is a IPv6 working group last call for comments on advancing the 
> following document as an Informational RFC:
> 
> 	Title		: IPv6 Node Requirements
> 	Author(s)	: J. Loughney
> 	Filename	: draft-ietf-ipv6-node-requirements-04.txt
> 	Pages		: 20
> 	Date		: 2003-6-30
> 
> Please send substantive comments to the ipng mailing list, and minor 
> editorial comments to the authors.  This last call period will end on 15 
> July 2003.
> 
> Bob Hinden / Margaret Wasserman
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Thu, 10 Jul 2003 15:01:30 +0300

Brian,

That seems like a reasonable addition.

John

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 10 July, 2003 11:30
> To: [email-masked]
> Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Requirements"
> 
> 
> > 4.3.1 Path MTU Discovery - RFC1981
> > 
> >    Path MTU Discovery [RFC-1981] MAY be supported.  
> 
> I don't propose to change this, for reasons that were discussed
> earlier. But I do wonder if we shouldn't qualify it slightly,
> since we would hope to see the majority of nodes supporting
> MTU discovery. Could we add a sentence saying something like
>  It is expected that most implementations will indeed support
>  this, although the possible exception cases are sufficient
>  that the used of "SHOULD" is not justified.
> Otherwise, some implementors might use the MAY as an easy way out.
> 
>     Brian
> 
> Bob Hinden & Margaret Wasserman wrote:
> >

---

From: "Dave Thaler" <[email-masked]>
Date: Sun, 13 Jul 2003 14:44:29 -0700

> editorial comments to the authors.  This last call period will end on
15

I did find a bunch of editorial nits which I will send to the editor.
The following issues are more substantive:

Section 4.2:
>  Neighbor Unreachability Detection (NUD) ... is required for
multicast.

What does that mean?  You don't do NUD for multicast addresses.

4.6:
>   supporting multicast applications. A primary IPv6 multicast
>   application is Neighbor Discovery (all those solicited-node mcast

Neighbor Discovery is not an "application".  ND is a network-layer
function, not an application-layer function.  Suggest:
    supporting multicast protocols and applications.  A primary IPv6
    multicast protocol is Neighbor Discovery (all those solicited-node
    multicast

> 9. Router Functionality
>   This section defines general considerations for IPv6 nodes that act
>   as routers.  It is for future study if this document, or a separate
>   document is needed to fully define IPv6 router requirements.
>   Currently, this section does not discuss routing protocols.

This needs to be resolved before this document is published as an RFC.
Making this document fully define router requirements would
significantly
delay publication (and this would certainly not be ready for last call).
Hence, I think this document should not document router requirements
at all, and leave that to a separate document.  That is, I would suggest
that section 9 be removed and put in a separate draft.

10:
>   Network Management, MAY be supported by IPv6 nodes.

What does this mean?  Does this specifically mean SNMP (if so say so).
If not, what is the purpose of this sentence?  It would basically be
saying "A node MAY support whatever configuration mechanism it
supports."
which seems odd to say.

>   In a general sense, MIBs SHOULD be supported by nodes that support a

Any MIBs in particular or just whatever the implementor wants?
For example are the MIBs mentioned in 10.1.1 and 10.1.2 SHOULDs or not?

12:
There's a lot of normative references to works in progress.
Will this hold up publication of this document until they're all RFCs?
If so, it might be good to see if some can turned into informative
references or removed.

-Dave