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

[Margaret Wasserman <margaret@thingmagic.com>]

Hi Alain,

At 6:23 PM -0700 7/15/04, Alain Durand wrote:
> There is a perception (at least from Margaret) that RFC3484 solves 
> the IPv4/IPv6 selection
> problem. I do not share that point of view. The issue is much more complex,
> as hinted in draft-ietf-v6ops-v6onbydefault.

It is likely that RFC 3484 doesn't resolve every address selection 
issue.  Also, RFC 3484 is complex, and I think that we would all be 
happier with a simpler solution to the address selection problem, but 
we haven't been able to find a simpler solution that actually works. 
Also RFC 3484 solves some serious issues that were identified with 
the single switch mechanism currently described in 
draft-ietf-v6ops-mech-v2.  Also, further progress in this area should 
be made in updates to RFC 3484.

If the v6ops WG believes that there are operational problems with RFC 
3484, we should clearly document them for consideration by the IPv6 
WG.  Or, better yet, we could just go to the IPv6 WG and propose 
solutions.

> Today, in the current state of IPv6 deployment, a single switch 
> on/off would not really be any worse
> than implementing RFC3484; however, this is not something you want 
> to say in a DS document.
>
> My opinion is that we should delete section 2.2 DNS all together, as 
> out of scope.

I am concerned about this option, because it seems to duck the 
problem...  Do you really think it would be okay to publish a 
specification for dual-stack nodes that is silent on the subject of 
address selection?  Without even including a reference to a separate 
specification that covers this topic?

IMO, RFC 3484 is better in many ways (and no worse in others) than 
the single on/off switch described in draft-ietf-v6ops-mech-v2.  So, 
we should be encouraging people to implement RFC 3484, not the single 
switch mechanism.

I believe rather strongly that it would be a mistake to re-publish 
the single switch address selection mechanism and advance it to DS 
when we know that a more complex mechanism is required.  I fear that 
this would cause confusion in the industry about what level of 
address selection support is required for a full IPv6 implementation.

The arguments for publishing this document without a normative 
reference to RFC 3484 seem to be motivated by the goal of publishing 
draft-ietf-v6ops-mech-v2 as a DS by somehow side-stepping the fact 
that it has known technical omissions in the area of address 
selection that we have attempted to address in RFC 3484.

This goal seems to be based on some assumptions that I don't 
necessarily agree with, most notably:

- The assumption that there is some large value to moving 
draft-ietf-v6ops-mech-v2 despite its technical flaws in the area of 
address selection, and/or

- The assumption that RFC 3484 can't (or won't?) be moved to DS any time soon.

Right now, we are not even talking about whether or not to publish 
draft-ietf-v6ops-mech-v2 at DS!  The requested publication status for 
this document is PS,  RFC 3484 is already at PS, and normatively 
referencing RFC 3484 in draft-ietf-v6ops-mech-v2 will not block 
publication of this document.

Also, we're all really the same group of people...  So, if we (as a 
group) consider publishing draft-ietf-v6ops-mech-v2 as a Draft 
Standard to be a high priority, we can do the work to move RFC 3484 
to DS as well.

I've worked with everyone involved here long enough to respect you 
and consider you to be reasonable people, so I feel like I may be 
missing something here...  So, what am I missing?

I don't want to assert my beliefs above those of the entire v6ops WG. 
At this point, though, too few people have weighed in on this issue 
for the opinion of the v6ops WG to be clear (to me, anyway), one way 
or the other.  What do other people think?

Margaret