Subject: Issue 29: AD REVIEW: IPv6 Node Requirements

From: [email-masked]
Date: Wed, 19 Nov 2003 16:43:59 +0200

NITS, my comments preceded by <JAL>:

   As it is not always possible for an implementer to know the exact
   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
   that they should adhere to John Postel's Robustness Principle:

      Be conservative in what you do, be liberal in what you accept from
      others. [RFC-793].

>> s/John Postel/Jon Postel/

<JAL> ack.

>> General comment:  The organization of this document is a bit
>> awkward.  It would probably read better to start with the
>> IP layer and put the Sub-IP Layer at the end.

<JAL> recommendation, no change.

3. Sub-IP Layer
   An IPv6 node must follow the RFC related to the link-layer that is
   sending packets.  By definition, these specifications are required
   based upon what layer-2 is used.  In general, it is reasonable to be
   a conformant IPv6 node and NOT support some legacy interfaces.

>> It is not clear to me what this paragraph is trying to indicate.
>> Perhaps:
>> An IPv6 node must include support for one or more IPv6 link-layer
>> specifications.  Which link-layer specifications are included 
>> will depend upon what link-layers are supported by the hardware
>> available on the system.  It is possible for a conformant IPv6
>> node to support IPv6 on some of its interfaces and not on others.

<JAL> proposed text is good.

   The capability of being a final destination MUST be supported,
   whereas the capability of being an intermediate destination MAY be
   supported (i.e. - host functionality vs. router functionality).

>> Is there a reason for this particular wording?  "Intermediate 
>> destination" is not a term that I'm familiar with.  Perhaps
>> this could be better said:  "All conformant IPv6 implementations
>> MUST be capable of sending and receving IPv6 packets; forwarding
>> functionality MAY be supported"?  Or are you trying to say more
>> here?

<JAL> proposed text is good.

4.5 Addressing

   Currently, there is discussion on support for site-local addressing.

>> Either say more or leave this out?  When published as an RFC, this
>> document will live long term, so the word "currently" is a bit
>> vague.  Since we are deprecating site-local, I think that you
>> could just omit any mention of it.

<JAL> proposal is good.

4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710

   If an application is going to join any-source multicast group
   addresses, it SHOULD implement MLDv1. When MLD is used, the rules in
   "Source Address Selection for the Multicast Listener Discovery (MLD)
   Protocol" [RFC-3590] MUST be followed.

>> If I understand correctly, these nodes could support either
>> MLDv1 or MLDv2.

<JAL> MLDv2 includes MLDv1 functionality, no change needed.

5.1 Transport Layer

5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147

   This specification MUST be supported if jumbograms are implemented
   [RFC-2675].  One open issue is if this document needs to be updated,
   as it refers to an obsoleted document.

>> An open issue for whom?  I wouldn't include open issues for
>> other documents in this document.

<JAL> Remove open issue text.

   Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be
   supported if applications on the node use URL's.

>> s/Format/"Format/  ??

5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732

   RFC 2732 MUST be supported if applications on the node use URL's.

>> This is redundant with the last line of the previous section.

<JAL> deleted last line of previous section.

5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315

>> I think that you should be explicit, throughout this section,
>> that you are talking about DHCPv6.  In other words, replace
>> all occurances of DHCP with DHCPv6.  It is possible that nodes
>> may implement DHCP(v4), but not DHCPv6.

<JAL> Thought that would go without saying, but I'll be explicit noone 
gets confused.

10.1 Management Information Base Modules (MIBs)
 
   The following two MIBs SHOULD be supported MIBs by nodes that support
   an SNMP agent.

>> s/supported MIBs by/supported by/

<JAL> ok

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------