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

I support this move as in Reliance we are heavily banking upon this technology for our  deployment.

With regards,

B.Nagaraj

Cabin 3, 2nd floor, 2A /Cabin 8, B wing, 3rd floor, TC 23
RCP complex,
Thane Belapur Road
Ghansoli, Navi Mumbai-400701

Phone:
Work: +912244773047 / +912244787958
Mobile: +919867564147

From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva)
Sent: Wednesday, November 12, 2014 1:51 PM
To: Ted Lemon
Cc: Softwires WG
Subject: 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
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."