Brian Haberman writes: > Here are my comments on the Address Selection draft. I think it > is in really good shape and only have a few > comments/questions/suggestions. Many of these are related to text > directly inherited from RFC 3484, so I am willing to listen to push back on > making those changes. > > 1. The first line of the Abstract does not read well. I suggest changing it > to "... > two algorithms, one for source address selection and one for...".
Done > 2. There has been resistance to having normative text in the Abstract > and the first sentence of the second paragraph certainly sounds > normative. Any objection to striking that first sentence? Would it > make sense to move that sentence to the last paragraph in the Introduction? Reworded to not sound normative. Now reads: "Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers." > 3. The fourth paragraph of section 2 says apps SHOULD iterate through > the list of addresses returned from getaddrinfo(). It would be useful > to identify what exceptions to that rule are reasonable. Changed to "Well-behaved applications SHOULD NOT simply use the first address returned from getaddrinfo() and then give up if it fails. For many applications, it is appropriate to iterate through the list of addresses returned from getaddrinfo() until a working address is found. For other applications, it might be appropriate to try multiple in parallel (e.g., with some small delay in between) and use the first one to succeed." I believe this is still in line with the intent of the original WG recommendation, but takes into account happy-eyeballs-like solutions. > 4. Section 2.1 (6th paragraph) mentions ULAs and 6to4 without > expansion or reference. It would be good to spell out what those are. Expanded ULA. Added references to both. (Reference to 6to4 RFC was already later in the same paragraph, so moved it up to first use.) > 5. I am curious as to what the rationale was for changing the text in > section 2.2 as opposed to keeping the original text from RFC 3484. In > making that change, why is only the length of S's prefix listed as a stopping > criteria for comparison? The rationale is explained in Appendix B, point 1 of the second list. > 6. In section 3.1, I find it confusing to discuss "unicast site-local" > and not mention the scope of ULAs. In fact, it may be worthwhile to > mention in section 2.1 that the placement of FEC0::/10 is based on the > site-local prefix having been deprecated. Some people would prefer to map ULAs to the multicast site-local scope, but doing so was contentious. So the scope is global per RFC 4193 "In practice, applications may treat these addresses like global scoped addresses." Added "(Note that ULAs are considered as global, not site-local, scope but are handled via the prefix policy table as discussed in Section 10.6.)" It's also mentioned in point 2 of the first list in Appendix B. Point 3 of that list explains the placement of fec0::/10. Discussion of the placement of the rows is not appropriate in section 3.1, which is about the rules that explicitly use scope(), which are separate from the rules using the prefix policy table. > 7. Section 5 states "...the remaining rules are applied (in order) to > ...". I would like to see this rule strengthened with the use of MUST > or SHOULD. The RFC style guide says to "avoid overuse of MUST". However since the previous phrasing already implied it's a MUST, I've gone ahead and changed "are applied" to "MUST be applied" as a purely editorial clarification. > In addition, the last paragraph in the section may lead > some implementers to consider some of the rules as optional. Is that really > what we want? I think that's a holdover from a very early version of the draft that led to RFC 3484. As you noted from the previous abstract text, it's all mandatory. (Of course some rules are no-ops like if you don't implement mobility, then "prefer home" vs "prefer care-of addresses" in source addr selection is a no-op.) The sentence Brian refers to is " Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability." I've dropped that sentence because of the confusion Brian suggests and because dropping it doesn't actually change any requirements not already stated elsewhere. > 8. This comment is driven by text in Section 6, but there are other > cases throughout the document. In several places, I find "should" and > "may" being used in situations where it could be normative. Is the > intent to interpret > mixed- and lower-case 2119 keywords as normative? "may" always means "MAY" when specifying behavior, and means "might" when talking informatively. Similarly, "should" always means "MUST" when specifying behavior. I've gone and replaced all uses of "should" and "may" as appropriate, to be consistent with the original meaning. > 9. Section 7 contains an indirect reference to a rule by using "Rule > 5.5". It would read better if it said something like "Rule 5 in > Section 5" or something similar. Yes this was confusing since both source and destination address selection algorithms have numbered rules. Changed to "source address selection (Section 5) Rule 5.5" > Once we resolve these, the draft can move along to IETF Last Call. I believe these should all be resolved now. -Dave > > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
