Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt

[Margaret Wasserman <margaret@thingmagic.com>]

Hi All,

A few weeks ago, Pekka Savola sent a summary of IESG
comments to the list that included:

>  1) section 2.2 on DNS result ordering/filtering seems to
>  be considered inappropriately short, and it would be better
>  to just refer to the default address selection RFC3484.
>  (Margaret Wasserman). Filtering is inappropriate (Ted Hardie
>  and Scott Hollenbeck).

The length of the section doesn't bother me.  In fact,
following my suggestion would make it shorter :-).

My objection to this section is that it contains a
simple set of address selection rules, including a
simple preference for IPv4 or IPv6, that has several
well-understood problems.  Those problems were
identified and addressed in RFC 3484.  So, I believe
that we should remove the address selection rules
specified in this section and replace them with a
normative reference to RFC 3484.

>  ==> possibilities include at least:
>  a) keeping the current tense of specifying a "simple" address
>     selection, and referring to RFC3484 for more details, but reword
>     the text appropriately.  Remove filtering but keep ordering. It
>     might require some convincing to make the IESG accept this
>     approach.  (In other words, a simple dual-stack implementation
>     would not necessarily have to implement RFC3484 to be
>     compliant/interoperable with this spec.)

There are several reasons why I do not believe
that this is a good choice.  We know that the simple
address selection (flag to prefer IPv4 or IPv6) does
not work properly. For instance, it causes situations
where global communication will be initiated using a
local source address, even when a global source address
is available.  It also causes situations where hosts
will prefer tunnelled communication over non-tunnelled
communication.

These problems were identified and fixed in RFC 3484,
which is a mandatory part of IPv6.

>  b) remove most of the text, referring to RFC3484.  Note that RFC3484
>  is PS, and we could not advance to DS if we did that.  (In other
>  words, all the dual-stack implementations compliant with this spec
>  would also have to implement RFC3484.)

This is my suggestion.

IMO, the concern that adding a normative reference
to RFC 3484 will prevent promotion to draft standard
is misplaced.  Before moving to DS, a draft must have
two interoperable implementations and "successful
operational experience".  The whole purpose of the
multi-tiered standards process is to identify problems
(such as the address selection problems in this draft)
and correct them before documents move to higher
levels of the standards track.

Margaret