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:[email protected]] 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" <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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."
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
