[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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
> July 2003.

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

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

>   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

> 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
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.

>   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
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?

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.


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 majordomo@sunroof.eng.sun.com