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

[Pekka Savola <pekkas@netcore.fi>]

Hello all,

(co-chair hat on)

I'd like to move forward with this by submitting a revised I-D before 
the revision cutoff on Monday.

There was just one comment to this thread, and some off-list
discussion between Margaret and the authors/editors.

I see three kinds of potential resolutions:

 1) Just remove a bit of text and refer normatively to RFC3484.
    This makes it impossible to go for Draft Standard soon.

    If this is done, IPv6 WG must be rechartered to add revising
    RFC3484 to Draft Standard in its deliverables.

 2) Keep the text basically as is.  The draft can't go forward unless 
    Margaret changes her opinion though.

 3) Remove a bit of text, refer informatively to RFC3484, and 
    basically say "DNS result ordering is out of scope of this 
    specification".  (This is a new compromise proposal.) That way, we 
    don't propose the "simple" ordering rules, but don't require 
    implementation of RFC3484 (in this spec) either.

Thoughts?

(co-chair hat off)

If my own opinion is worth anything.. 1) would be inappropriate
because RFC3484 revision isn't even on the IPv6 WG radar yet, and even
if it was, it would probably take a year at least; 3) might be a
reasonable compromise; obviously, I'd prefer 2).. :)

---------- Forwarded message ----------
Date: Mon, 14 Jun 2004 08:53:13 -0400
From: Margaret Wasserman <margaret@thingmagic.com>
To: v6ops@ops.ietf.org
Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt


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