Here are some comments from Margaret. John
> -----Original Message----- > From: Wasserman Margaret (NRC/Boston) > Hi John, > > I have reviewed the IPv6 Node Requirements draft. In general, > I think tha the document looks good, but I do have several comments > (attached). I believe that an update will be required before this > draft will be ready to go to IESG review. > > Margaret > > --- > > My comments are marked with '>>'. I've tried to included enough > context to make it clear what section I'm commenting on, but if > there is any question, please ask. > > 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/ > > >> 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. > > 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. > > Nodes MUST always be able to receive fragment headers. > However, if it > does not implement path MTU discovery it may not need to send > fragment headers. However, nodes that do not implement > transmission > of fragment headers need to impose a limitation to the payload size > of layer 4 protocols. > > >> There is no connection, as far as I know between implementing > >> Path MTU discovery and the need to implement fragmentation. > >> Path MTU is optional, and if it is not included the IP layer > >> will not send any packet over 1280 bytes (per RFC 2460). > >> Fragmentation isn't optional, because it is not always possible > >> for an upper layer to know the effective MTU, as the upper layers > >> may not know which interface will be used and/or what options > >> will be included in its packets. The IP layer must be capable > >> of fragmenting longer packets to the discovered Path MTU or > >> 1280. > > 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? > > 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. > > 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. > > 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. > > 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. > > 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. > > 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/ > > 11. Security Considerations > > >> In the IPsec section, you mention that other security issues > >> will be covered in the Security Considerations section, but > >> I don't see any issues here... > >> > >> Why aren't privacy addresses covered in this document? > >> > >> Also, did you consider a recommendation that IPv6 nodes should > >> implement SEND? Perhaps you should at least mention the > >> security issues with ND and indicate that the SEND group is > >> working to resolve them? > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
