I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Gruesse, Carsten --------------------------------- Document: draft-ietf-6man-rfc3484bis-05 Title: Default Address Selection for Internet Protocol version 6 (IPv6) Reviewer: Carsten Bormann Review Date: 2012-06-17 IETF Last Call Date: 2012-06-01, for 2012-06-15 IESG Telechat Date: 2012-06-21 ** Summary: This document is ready for publication after some editorial fixes, but it could benefit from some additional documentation as specified below. ** (Major:) Three types of address selection are often relevant to applications: -- initiator address selection (source and destination). This appears to be addressed here. -- responder address selection. This is mostly relevant where the responder cannot simply turn around the addresses chosen by the initiator. This may be because of multicast, or because of API deficiencies. -- listening address selection. An application needs to select the addresses to bind to. Experience from the ETSI CoAP plugfest shows that all three types of address selection are likely stumbling blocks when building an IPv6 implementation of a UDP-based protocol. RFC 3484 only seems to address initiator address selection, so it is logical that a -bis follows suit (but then, the security considerations seem to discuss responder address selection). Still, this is a major problem that maybe can be solved in additional documents. I believe the specification needs to be much clearer on who is its target. The document does not fully indicate which part of a system is supposed to act on its mandates. It just says The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. so there seems to be an assumption some part of the system other than an application or "upper-layer" may or should act on it. It then goes ahead and identifies getaddrinfo() explicitly as a target for destination address selection and "the network layer" for source address selection unless done by the application. Are other parts of a system subject to these mandates? Should an application writer that finds a working getaddrinfo() and a network layer read this document? Should an application layer protocol specification have to reference this document? There is also an assumption that the part of the system responsible for implementing this specification has certain information available to it (e.g., some knowledge is required to detect IPv4-converted addresses as such). This should be made much more explicit. ** (Minor:) Define term "scoped address prefix". (Maybe a section on terms would be useful; this could also be used to expand the many unexplained abbreviations used.) Last paragraph of 5 gives a "MUST be implemented" to Rule 2 only. -> expressio unius est exclusio alterius So clearly there is no MUST for the other rules? ** (Nit:) 2.1, in the paragraph "One effect", clarify that the document at this point hasn't said everything that is needed to derive this. As in: "As will become apparent later, ..." 3.1 could be explicit instead of being posed as a riddle. 5, 6: Saying every single rule twice (once for xA re xB and then for xB re xA) is tiring. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------