Subject: AD Review : draft-ietf-6man-rfc3484bis

From: Brian Haberman <[email-masked]>
Date: Mon, 21 May 2012 14:49:42 -0400

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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 31 May 2012 21:24:14 +0000

Brian Haberman writes:
> 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

> 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."

> 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.)

> 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.

> 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.
 
> 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.
 
> 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.

> 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-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------