[Softwires] map-t to proposed standard rather than experimental
Ted Lemon <Ted.Lemon@nominum.com> Tue, 11 November 2014 21:12 UTC
Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16611ACDAC for <softwires@ietfa.amsl.com>; Tue, 11 Nov 2014 13:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPN82wpTVfJ3 for <softwires@ietfa.amsl.com>; Tue, 11 Nov 2014 13:12:03 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF5D1ACD68 for <softwires@ietf.org>; Tue, 11 Nov 2014 13:12:03 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id A8BD5DA01A8 for <softwires@ietf.org>; Tue, 11 Nov 2014 21:11:33 +0000 (UTC)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E160953E07E for <softwires@ietf.org>; Tue, 11 Nov 2014 13:11:32 -0800 (PST)
Received: from dhcp-8fde.meeting.ietf.org (31.133.143.222) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 11 Nov 2014 13:11:21 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <04453287-AE2D-47DF-80FF-2C717AE1B23E@nominum.com>
Date: Tue, 11 Nov 2014 11:11:11 -1000
To: Softwires WG <softwires@ietf.org>
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [31.133.143.222]
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/har0w0OkPtcdWtCrq5Fbc7FGplA
Subject: [Softwires] map-t to proposed standard rather than experimental
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 21:12:05 -0000
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] map-t to proposed standard rather tha… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rajiv Asati (rajiva)
- Re: [Softwires] map-t to proposed standard rather… B.Nagaraj
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Ida Leung
- Re: [Softwires] map-t to proposed standard rather… Mallette, Edwin J.
- Re: [Softwires] map-t to proposed standard rather… Mallette, Edwin J.
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… HALLE Fabrice
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Xing Li
- Re: [Softwires] map-t to proposed standard rather… Petersen, Matt J
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Ole Troan
- Re: [Softwires] map-t to proposed standard rather… Wojciech Dec
- Re: [Softwires] map-t to proposed standard rather… Xing Li
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Tom Taylor
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Tom Taylor
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després