All,
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...".
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?
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.
4. Section 2.1 (6th paragraph) mentions ULAs and 6to4 without expansion
or reference. It would be good to spell out what those are.
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?
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.
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. 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?
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?
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.
Once we resolve these, the draft can move along to IETF Last Call.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
