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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
