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.