Re: [Softwires] map-t to proposed standard rather than experimental

[Rémi Després <[e-mail]>]

Hi Ted,

You are right in that an old decision may always be revisited before casting it in concrete.
Yet, changing an old decision has to be done carefully, especially if consequences of the change haven’t been documented.
Comments below suggest that wisdom is rather to maintain the old decision as it is: only one standard for stateless IPv4 connectivity across IPv6-only domains.

Le 11 nov. 2014 à 22:11, Ted Lemon <[e-mail]> a écrit :

> Dear softwire participants,
> 
> As we've gotten closer to finally finishing the stateless address-sharing suite of softwire specifications, I've had to explain what happened to a number of different people, both in the directorates and on the IESG, and even to nomcom.  As a consequence I've had to do a lot of thinking about why things wound up the way they did, and whether what happened was the right outcome.
> 
> As a result of the directorate reviews and the IESG review, it became clear that the plan to advance MAP-T as experimental didn't make sense.
AFAIK, not at all as clear as you say:
- If  both MAP-E and MAP-T would become standard, CPE providers would need to support (and maintain) both. 
- If both would become standard, full transparency to IPv4 fragmentation, which is guaranteed with MAP-E but not with MAP-T, would no longer be guaranteed to any customer, due to multiple standards.
- If an ISP domain would activate both, CPEs would have to select one of the two standards for their transmissions, with AFAIK no advice on how to do it. 

> The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make a lot of sense when presented together.

MAP-E and lw4over6 make a lot of sense, yes, but not with MAP-T in addition:
- MAP-E is and lw4over6 have well separated uses ( stateless and static, stateful and dynamic)
- MAP-E and MAP-T are two different solutions for essentially the same use. (Their DHCPv6 commonality is not an operational consideration.)

>   Because of this there is no reason that one should be experimental and the other two standards track.

The above shows that there are such reasons. 
Deciding such a change without re-visiting technical arguments would depart from customary IETF practice.
While the consensus on making MAP-E the only standard has held for long, re-visiting technical arguments would lead to an undesirable extra delay before the already-over-awaited MAP finalization.

> I would therefore like the working group to consider changing the proposed status of MAP-T to Proposed Standard.   

> I think this would be a less confusing outcome.   

Completely opposite view, based on the above.

> If the working group agrees, we would go through a second IETF last call and then advance the document.
> 
> I have not made the same suggestion with respect to 4RD because it actually is quite different from the other three documents.

Wise decision, in line with the current WG consensus.

>   This is not intended as an editorial comment about 4RD: rather, it's simply that I think the three documents together offer a good suite of solutions that can be understood and implemented together, whereas 4RD is essentially its own solution.   I think the working group has already chosen to advance the MAP-style lightweight solutions, and it would actually be confusing to advance 4RD as a separate standard solution.

> Suresh and Cui Yong will be asking the working group to weigh in on this issue, and then assuming no blocking objections are raised we will re-do the IETF last call for map-t as a proposed standard.

What makes objections to become blocking may be unclear, but I hope that the above will be enough for the WG to maintain its old and wise consensus.

Best regards,
RD


> 
> Thanks!
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires