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