[Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

Alain Durand <adurand@juniper.net> Wed, 01 February 2012 16:32 UTC

Return-Path: <adurand@juniper.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA921F8C5D for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 08:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.979
X-Spam-Level:
X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTLJKfhQBHzu for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 08:32:53 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4121F8A9C for <softwires@ietf.org>; Wed, 1 Feb 2012 08:32:48 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTylpL+2PAqh+ki4UDk/3+HgM/vmAehgm@postini.com; Wed, 01 Feb 2012 08:32:53 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 1 Feb 2012 08:28:43 -0800
From: Alain Durand <adurand@juniper.net>
To: Softwires WG <softwires@ietf.org>
Date: Wed, 01 Feb 2012 08:28:40 -0800
Thread-Topic: Moving forward with 4rd-T, 4rd-E & 4rd-U
Thread-Index: Aczg/o/r7v3+nerQQUWkiU5+ojD5Aw==
Message-ID: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 01 Feb 2012 16:32:54 -0000

Dear wg,

We now have a number of documents and solutions on the table in the 4rd category: all the MAP effort, including 4rd-T & 4rd-E,
and, somehow separately, the 4rd-U effort. I will claim that there is a very large overlap between all those solution and somehow small differences.
For the sake of this discussion, I'll say the overlap is about 90%, the exact number is irrelevant, what matters is that this number is much more than 50%

I have expressed many times that, in my view, the main role of a standard process is to pick one solution when multiple are available. Not that
the others are bad, but that the fact of not choosing and pushing through the process a number of solutions that are 90% or more identical is not doing
the community any good.

Back at Beijin interim meeting, we agreed on 'publishing' a number of documents, but did not agree on status and/or recommendation
attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying then.

At stake here is not so much the organization of the document set, nor which document(s) are accepted as wg item(s) right now
on the basis that they are somehow technologically 'ready'.

At stake now is how many solutions that are 90% overlapping we are going to send to the IESG. In other words,
at stake is the capability of this wg to make clear recommendations  as to what to implement and what to deploy.

At this point in time, I think the wg as the choice between a number of paths forward:

1) Declare failure to reach consensus and stop working on this 4rd space.
2) Declare a Pyrrhic(*) victory, publish everything on the standard track without any recommendation as to which one to use
3) Declare partial victory, publish everything as Experimental, let the market decide and come back in two years
     to put the winner on the standard track.
4) Converge to a consensus toward one 'recommended' solution, publish that one as Standard track and publish the
     other ones as experimental/informational, THEN declare victory. Note that using standard track vs experimental is just one way
     to make recommendations on status, there are others, such as publishing a recommendation document or adding
     recommendation text in a boiler plate inside each document.

I'd think that we would all agree that 1) is the least preferred option.

2) might be appealing as a short term solution to (not solve) the recommendation problem we are faced with, but if we do that,
I would claim that the wg would have not done its job and would have simply added to the confusion around
which transition mechanism to choose. Hence my qualification of this solution as 'Pyrrhic' victory.

As wg co-chair, my perspective is that we should do either 3) or 4)

I would like to encourage the wg to start a discussion toward 4) on the mailing list so that we could have a productive conversation in Paris,
where I intend to ask for wg feedback on this question.

More over, 4rd-U claims to solves a number of issues that the MAP suite of documents does not address. It would be beneficial to have
a discussion on the mailing list  to see if a) those issues are important or not and b), if they are, are they properties of 4rd-U or could they be solved as well
in MAP, they just have not been addressed there yet.

In the mean time, I believe we should hold off accepting any document as wg item. I'd like to use the upcoming Paris meeting
next month as a forcing function to make progress and I encourage discussion on the mailing list on thee above topics until then.

     Alain, Softwire wg co-chair.


(*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory