Jim, You don't need to worry, I'll address the Thomas' points, and try to get the document in good shape. I don't see anything unreasonable in Thomas' comments, so it shouldn't be a big deal to get things in order.
thanks, John > -----Original Message----- > From: ext Bound, Jim [mailto:[EMAIL PROTECTED] > Sent: 01 September, 2003 11:14 > To: Thomas Narten; [EMAIL PROTECTED] > Subject: RE: AD review of draft-ietf-ipv6-node-requirements-05.txt > > > WG Members, > > I want to fully support this AD review and feel the node requirements > draft is not ready to be published even as informational until this > excellent review is answered in detail. I do not believe an > informational document should ever override and existing > standards track > document ever in our community, and that is not a good practice. > > My input is this document cannot move forward. > If you want to discuss my second sentence above its my opinion and I > suggest the WG not focus on that statement because it will > slow down the > progression of this document. It for now is rhetorical > comment. If you > want to discuss with me offline that is fine with me. > > Respectfully, > /jim > > > -----Original Message----- > > From: Thomas Narten [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 27, 2003 5:30 PM > > To: [EMAIL PROTECTED] > > Subject: AD review of draft-ietf-ipv6-node-requirements-05.txt > > > > > > The WG has asked this be published as an Informational > > document. Here are my review comments. I assume some > > discussion and a revised ID will be needed before I forward > > the document to the IESG as a whole. > > > > Note: some of these points may best be responded to by > > starting a separate thread, so folk can easily follow > > individual topics of interest. > > > > Thomas > > > > substantative (more or less...): > > > > General comment. There are places in the document where it is > > not immediately clear whether something is required to be > > implemented or not. Sometimes the wording is just "support", > > and in the context of the wording, this may depend on > > deployment considerations. I would except that the purpose of > > this document is to make it clear what needs to implemented. > > I mention some specific cases below, but may not have caught > > them all... It might be good to scan the document for > > "support" and check that the intent is clear. > > > > > 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. > > > > This would seem inconsistent with the following wording in RFC 2460: > > > > In response to an IPv6 packet that is sent to an IPv4 > destination > > (i.e., a packet that undergoes translation from IPv6 to > IPv4), the > > originating IPv6 node may receive an ICMP Packet Too Big message > > reporting a Next-Hop MTU less than 1280. In that case, > > the IPv6 node > > is not required to reduce the size of subsequent packets > > to less than > > 1280, but must include a Fragment header in those packets > > so that the > > IPv6-to-IPv4 translating router can obtain a suitable > > Identification > > value to use in resulting IPv4 fragments. Note that this > > means the > > payload may have to be reduced to 1232 octets (1280 minus > > 40 for the > > IPv6 header and 8 for the Fragment header), and smaller still if > > additional extension headers are used. > > > > > Router Discovery is how hosts locate routers that reside on an > > > attached link. Router Discovery MUST be supported for > > > implementations. However, an implementation MAY > support disabling > > > this function. > > > > Why the MAY above? If there are reasons to allow this, it > > would be good to give some examples of the WG's thinking for > > calling out such an exception. Also, this is a change to 2461 > > I assume? > > > > > Prefix Discovery is how hosts discover the set of > > address prefixes > > > that define which destinations are on-link for an > attached link. > > > Prefix discovery MUST be supported for implementations. > > However, the > > > implementation MAY support the option of disabling > this function. > > > > same comment with regards to MAY. And also, am I right to > > assume that disabling this function would need to be done on > > a per-interface basis (in which case the current text isn't > > explicit enough)? I.e, is this related to some 3G type deployment? > > > > > Duplicate Address Detection MUST be supported (RFC2462 > > section 5.4 > > > specifies DAD MUST take place on all unicast addresses). > > > > This reference to 2462 section 5.4 is a tad misleading. The > > relevant paragraph in 2462 says: > > > > > 5.4. Duplicate Address Detection > > > > > > Duplicate Address Detection is performed on unicast > > addresses prior > > > to assigning them to an interface whose DupAddrDetectTransmits > > > variable is greater than zero. Duplicate Address > > Detection MUST take > > > place on all unicast addresses, regardless of whether they are > > > obtained through stateful, stateless or manual > > configuration, with > > > the exception of the following cases: > > > > Note that one of the exception cases is stateless addr conf > > when configuring multiple addresses using the same IID. Is > > node-requirments trying to override this exception? If so, it > > should be explicit about it. Otherwise, I'm not sure why the > > above sentence is included in node-requirements. > > > > > 4.5.4 Default Address Selection for IPv6 - RFC3484 > > > > > > Default Address Selection for IPv6 [RFC-3484] SHOULD be > > supported, if > > > a node has more than one IPv6 address per interface or > a node has > > > more that one IPv6 interface (physical or logical) configured. > > > > > > If supported, the rules specified in the document MUST be > > > implemented. A node needs to belong to one site, however > > there is no > > > requirement that a node be able to belong to more than > one site. > > > > This is really weasle worded. Is 3484 mandatory to > > _implement_ or not? You can't make its implementation > > dependent on whether there are multiple addresses, since the > > number of addresses a node will have is not something an > > implementor will know, as it's an operational issue. > > > > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], > > [RFC-3152] > > > and [RFC-3363] MAY be supported. Not all nodes will > > need to resolve > > > names. Note that RFC 1886 is currently being updated > > > [RFC-1886-BIS]. > > > > 1886-bis has been approved by the IESG I believe... > > > > Also, I suspect this section really needs to talk about > > resolvers and resolver behavior, rather than just say DNS. > > Most of the server issues do not apply to generic IPv6 nodes. > > But almost every node will have some sort of resolver... > > > > > 5.3.1 Managed Address Configuration > > > > IMO, it doesn't make sense to talk about "implementing DHC" > > without being more specific. I suspect that all of this > > section is about the client part of DHC, not the server. It > > would be good to make this clear. Ditto for 5.3.2. > > > > Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be used to > > obtain configuration information. A node that uses stateless DHCP > > must have obtained its IPv6 addresses through some other > mechanism, > > typically stateless address autoconfiguration. > > > > Does this even need mentioning? I.e, what are the real > > implications for clients? Do they need to implement full > > blown dhc (the client part)? Or do they implement some > > subset? (Hmm... reading the related draft, clients implement > > a subset... And this document has a normative reference to > > the other ID, so either this document needs to be more > > explicit about what stateless DHCPv6 is, or will have to wait > > on the other document.) > > > > > 6.1 Transition Mechanisms > > > > > > IPv6 nodes SHOULD use native addressing instead of > > transition-based > > > addressing (according to the algorithms defined in RFC 3484). > > > > Is this a statement about what needs to be implemented? Or is > > this an operational statement? (This document seems to be > > mostly about the former, and this statement seems odd without > > more context...) > > > > > Routers do not need to support route optimization or home agent > > > functionality. > > > > > > Routers SHOULD support the generic mobile IP requirements. > > > > I think it would be better to replace the above with something like: > > > > Routers SHOULD support the router-specific extensions defined in > > Section 8.3 of MIPv6 > > > > And include a normative reference to the document. > > > > > 7.2 Securing Signaling between Mobile Nodes and Home Agents > > > > > > The security mechanisms described in [MIPv6-HASEC] MUST > > be supported > > > by nodes implementing mobile node or home agent functionality > > > specified in Mobile IP [MIPv6]. > > > > So would presumably the applicable parts of Section 8 of the > > mipv6 spec. Better to cite them explicitely. > > > > > Generic Packet Tunneling [RFC-2473] MUST be supported for nodes > > > implementing mobile node functionality or Home Agent > > functionality of > > > Mobile IP [MIPv6]. > > > > This may not need mentioning, as it may already be covered in > > Section 8 of the mipv6 spec. > > > > Actually, this entire section may warrant rethinking given > > the existance of Section 8 in the MIPv6 spec. > > > > Section 9 begins by saying: > > > > > 9. Router-Specific Functionality > > > > > > This section defines general host considerations for > > IPv6 nodes that > > > act as routers. Currently, this section does not > discuss routin- > > > specific requirements. > > > > an then immediately says > > > > > 9.1.1 IPv6 Router Alert Option - RFC2711 > > > > > > The Router Alert Option [RFC-2711] MUST be supported by > > nodes that > > > perform packet forwarding at the IP layer (i.e. - the node is a > > > router). > > > > But this seems like a "forwarding-related" requirement. When > > do routers send router alerts? They need to process them when > > they are received, e.g., as part of MLD stuff. When else are > > they used? > > > > > 11. Security Considerations > > > > This section seems both too detailed and not detailed enough. > > Too detailed in that it talks about security issues related to some > > (arbitrary?) protocols like ICMPv6, but not detailed enough > > in that it is anywhere complete and doesn't mention many > > other protocols that could also be included if one were to > > include ICMPv6. My suggestion would be to up-level here and > > not talk about detailed security issues of individual > > protocols. If you want to do that, point to the security > > sections in other documents. But if you do this, you'll have > > a hard time deciding whether to mention every document or just some. > > > > Does _this_ document itself introduce or raise any security > > issues not covered elsewhere? That is the question this > > document should focus on. The answer may be mostly no. > > > > Finally, there are an awful lot of references to IDs in the > > normative section. That's a problem. See defn. of normative > > in draft-rfc-editor-rfc2223bis-06.txt. > > > > Nits/editorial: > > > > > The goal of this document is to define the set of functionality > > > required for an IPv6 node; the functionality common to > > both hosts and > > > routers. Many IPv6 nodes will implement optional or additional > > > > Sentence with semi-colon doesn't parse. :-( > > > > > 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 > > > > > > Transmission of IPv6 Packets over Ethernet Networks > > [RFC-2464] MUST > > > be supported for nodes supporting Ethernet interfaces. > > > > I don't quite like the way this (and subsequent) sentences is > > worded. We don't want to imply that nodes that support IPv4 > > over Ethernet must also support this... > > > > How about: > > > > Nodes supporting IPv6 over Ethernet interfaces MUST implement > > Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. > > > > same applies to remaining LL sub-sections. > > > > > IPv6 over ATM Networks [RFC2492] MUST be supported for nodes > > > supporting ATM interfaces. Additionally, the > > specification states: > > > > what does "the specification" refer to? How about saying > > > > Additionally, RFC 2492 states: > > > > > > > > > option of disabling this function. The ability to > > understand specific > > > Router Advertisement optionss is dependent on supporting the > > s/optionss/options/ > > > specification where the RA is specified. > > > > s/the RA/the particular RA option/ > > > > > Redirect functionionality SHOULD be supported. If the node is a > > spelling > > > router, Redirect functionionality MUST be supported. > > > > > > > > > Path MTU Discovery [RFC-1981] MAY be supported. 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. The rules in RFC 2460 MUST be followed for packet > > > fragmentation and reassembly. > > > > Same comment applies here as mentioned earlier. > > > > > Nodes that are routers MUST be able to generate link > > local addresses > > > as described in this specification. > > > > "this specification" is ambiguious. Do you mean 2460? > > > > > > > If an application is going join any-source multicast, it SHOULD > > > support MLDv1. If it is going to support Source-Specific > > > Multicast, > > > > s/join any-source multicast/to join any-source multicast > > group addresses/ > > > > also: > > > > If an application is going join any-source multicast, it SHOULD > > support MLDv1. If it is going to support Source-Specific > > Multicast, > > it MUST support MLDv2 [MLDv2] and conform to the Source-Specific > > Multicast overview document [RFC3569]; refer to Source-Specific > > Multicast architecture document for details [SSMARCH]. > > > > > > Is worded oddly. If A, you SHOULD do MLDv1. If B, you MUST > > do MLDv2. Shouldn't the first SHOULD be a MUST as well? How > > can you not support MLDv1 if you are going to join multicast > > groups and not going to do MLDv2? > > > > > 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. > > > > Drop last sentence? I suspect it's irrelevant, as the updated > > that is needed is cosmetic/editorial, not substantative. Right? > > > > > > > This document is currently being updated. > > > > s/this document/RFC2893/ > > > > > > > 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473 > > > > nit: indention is wrong on this heading. > > > > > > > 3DES-CBC does not suffer from the issues related to > > DES-CBC. 3DES-CBC > > > and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be > > supported. AES- > > > 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is > > expected to > > > be a widely available, secure algorithm that is required for > > > interoperability. It is not required by the current IPsec RFCs, > > > however. > > > > Perhaps add to last sentence, "but is expected to become > > required in the future" ??? > > > > act as routers. Currently, this section does not discuss routin- > > specific requirements. > > > > s/routin/routing/ > > > > > > > At least the following two MIBs SHOULD be supported MIBs > > SHOULD be > > > supported by nodes that support an SNMP agent. > > > > duplicate words. > > > > > 10.1.1 IP Forwarding Table MIB > > > > > > Support for this MIB does not imply that IPv4 or IPv4 specific > > > portions of this MIB be supported. > > > > Which MIB is this? (No reference provided...) > > > > > 10.1.2 Management Information Base for the Internet Protocol (IP) > > > > Ditto. > > > > > 12.1 Normative > > > > > > [DHCPv6-SL] R. Droms, "A Guide to Implementing > > Stateless DHCPv6 > > > Service", Work in Progress. > > > > For all the references, please include the ID name, so folk > > can actually figure out which ID it refers to. Also the RFC > > editor will want to know this too, so they can put in the > > right references, in case any are already RFCs. > > > > -------------------------------------------------------------------- > > 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 PROTECTED] > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
