RE: APPSDIR review of draft-ietf-6man-rfc3484bis-05

[Dave Thaler <[e-mail]>]

Thanks for the review.
Making the changes for -06 now, responses below...

Carsten Bormann writes:
> Sent: Sunday, June 17, 2012 1:01 PM
> To: [e-mail] application-layer protocols; draft-ietf-6man-
> [e-mail]
> Cc: The IESG; [e-mail]
> Subject: APPSDIR review of draft-ietf-6man-rfc3484bis-05
> 
> 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.

Added the following text to section 2 (Context in Which the Algorithms Operate):

    Although source and destination address selection is most typically
    done when initiating communication, a responder also must deal
    with address selection.  In many cases this is trivially dealt
    with by an application using the source address of a received
    packet as the response destination, and the destination address
    of the received packet as the response source.  Other cases, however,
    are handled like an initiator, such as when the request
    was multicast and hence source address selection must still occur
    when generating a response, or when the request includes a list
    of the initiator's addresses from which to choose a destination.
    Finally, a third application scenario is that of a listening
    application choosing on what local addresses to listen.  This
    third scenario is out of scope for this document.

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

That's the intent of section 2.  It already explicitly says that destination 
address selection applies to APIs (which I've reworded as noted below,
to say it applies to APIs such as getaddrinfo rather than being possibly
read as just that one API in particular), and source address selection 
applies to the IPv6 network layer implementation.

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

Section 2 does contain a paragraph explicitly targeted at apps, which is:
    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.

Other than that paragraph the rest is already stated in section 2 
to be targeted at APIs (for destination address selection) and 
the IPv6 network layer (for source address selection).

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

OLD: As a consequence, we intend that implementations of getaddrinfo()
OLD: will use the destination address selection algorithm specified here
OLD: to sort the list of IPv6 and IPv4 addresses that they return.

NEW: As a consequence, we intend that implementations of APIs such as getaddrinfo()
NEW: will use the destination address selection algorithm specified here
NEW: to sort the list of IPv6 and IPv4 addresses that they return.

> Are other parts of a system subject  to these mandates?

Yes, Section 2 already states:
    Separately, the IPv6 network layer will use the source address
    selection algorithm when an application or upper-layer has not
    specified a source address.  Application of this specification to
    source address selection in an IPv4 network layer might be possible but
    this is not explored further here.


>  Should an application writer that finds a working
> getaddrinfo() and a network layer read this document?

The paragraph I mentioned in section 2 that explicitly targets application
developers certainly applies.  For the rest, I'm sure they'd find it useful, 
but not required reading, and it would be odd for an application to
claim conformance to this spec.  The abstract already states:
    Default address selection as defined in this specification applies
    to all IPv6 nodes, including both hosts and routers.

So they should gather from the abstract that it's not about an application
implementation, but rather a host/router implementation.

> Should an application layer protocol specification have to reference this
> document?

"have to"?  No.

"want to"?  Perhaps, if they wanted to explain to the reader why they
needed to define their own algorithm (if they did), or explain why they
didn't need to discuss it because the defaults in this document are 
sufficient.

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

I think it goes without saying that anything used in a MUST that applies to
a component (in this case an IPv6 network layer that explicitly supports SIIT)
has to have the relevant information available to it.   In other words, it 
seems explicit already in the case you cite.

> ** (Minor:)
> 
> Define term "scoped address prefix".

Reworded as "address prefixes that are not of global scope"
(to only use terms already used in section 1).

> (Maybe a section on terms would be useful; this could also be used to expand
> the many unexplained abbreviations used.)

The abbreviations already existed in RFC 3484.  However, I've
now expanded them on first use (SIIT, ISATAP, etc.).

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

This was an oddity that already existed in RFC 3484.
Moved up and reworded as a Discussion: point after rule 2.

> ** (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, ..."

Done.

> 3.1 could be explicit instead of being posed as a riddle.

The above comment was too much of a riddle for me to understand.  :)
The text in Section 3.1 already seems pretty explicit.

> 5, 6: Saying every single rule twice (once for xA re xB and then for xB re xA) is
> tiring.

Older consensus (RFC 3484) was that it was better to be explicit and there 
doesn't seem to be a significant gain in revisiting that and risking introducing
an error in some normative text in doing so.  Hence no change.

Thanks for the review,
-Dave