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

Ted,

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

That's quite reasonable. And I agree, especially given that few operators have already deployed and asked for the same.

If the working group agrees, we would go through a second IETF last call and then advance the document.

Could we not combine the LC and the question in 1-go?

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
CITT CTO Office

On Nov 11, 2014, at 11:12 AM, "Ted Lemon" <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>> wrote:

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.  The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make a lot of sense when presented together.   Because of this there is no reason that one should be experimental and the other two standards track.

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.   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.   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.

Thanks!
_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires