Re: two independent implementations (Re: draft-housley-two-maturity-levels)

"James M. Polk" <jmpolk@cisco.com> Wed, 27 October 2010 16:19 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0778C3A6803 for <ietf@core3.amsl.com>; Wed, 27 Oct 2010 09:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.54
X-Spam-Level:
X-Spam-Status: No, score=-110.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2wmKZcHWxOK for <ietf@core3.amsl.com>; Wed, 27 Oct 2010 09:19:37 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EA6FF3A67F2 for <ietf@ietf.org>; Wed, 27 Oct 2010 09:19:37 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.58,246,1286150400"; d="scan'208";a="610510333"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 16:21:28 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9RGLRlM018694; Wed, 27 Oct 2010 16:21:27 GMT
Message-Id: <201010271621.o9RGLRlM018694@sj-core-5.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 27 Oct 2010 11:21:26 -0500
To: Lars Eggert <lars.eggert@nokia.com>, "James M. Polk" <jmpolk@cisco.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: two independent implementations (Re: draft-housley-two-maturity-levels)
In-Reply-To: <AF08BD12-82BB-4B4C-99A2-5D4F2F2E4719@nokia.com>
References: <4CC6224B.5060300@gmail.com> <20101026024400.57137.qmail@joyce.lan> <201010260337.o9Q3b4Mb020219@sj-core-5.cisco.com> <AF08BD12-82BB-4B4C-99A2-5D4F2F2E4719@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 16:19:39 -0000

At 02:16 AM 10/27/2010, Lars Eggert wrote:
>Hi,
>
>On 2010-10-26, at 6:37, James M. Polk wrote:
> > I'm not in love with the 3 maturity levels, especially when I was
> > asked by an AD during Maastricht to provide proof of 2 independent
> > implementations just to have an ID I was presenting be considered to
> > become a WG item.
>
>I was that AD, and your characterization is not accurate. (I've 
>pointed this out privately before.)

I'll cop to the use of the word "proof" was stronger than it needed 
to be. It was still suggested though, even with another TSVWG author 
saying it was a good idea (Randy Stewart with SCTP).


>The issue was that it was difficult to judge - due to lack of WG 
>interest and review - whether interoperable specifications could be 
>built based on the document in question.

I think this gets to the core of what many of us have mentioned on 
the thread about Russ's proposal about two-maturity-levels: that 
whether or not two implementations can interoperate is the purpose of 
the PS level getting to the DS level, and should not be a basis for 
stalling an individual ID progressing to WG item (which you do admit 
to here in this email).

>I said that *if there were* multiple implementations, that that 
>would certainly demonstrate this nicely. But there are other ways, 
>such as more WG review activity, etc.

that (WG review) was ultimately (seemed to be) agreed to, but not 
right away - and it requested 5 full reviews before being considered, 
which is a high bar for either the Transport or RAI areas (that I'm 
familiar with over 11 years at the IETF).

***To everyone not familiar with TSVWG, we are chartered with 
progressing at least 5 different protocols and mechanisms. Room 
consensus is never easy for the chairs to realize due to the 5 
protocols and mechanisms are not close to each other topologically, 
other than they are all within the Transport realm. What I mean here 
is that if we have ~10 people in a room of 150 that claim interest in 
any of the charter items we chairs are ecstatic.***

There's another thing in play here, and that's who some (i.e., at 
least one AD) believe this extension is for (Military), and I'll 
repeatedly said I haven't heard this requirement from them (ever!), 
and haven't focused on that market segment for a couple of years now. 
Lars - you mentioned this target market when answering Fred during 
the (somewhat heated) TSVWG discussion in Maastricht.

We can talk more about that whenever you want, say in 2 weeks?

James


>Lars
>
> From the Maastricht minutes:
>
>     Lars: One way is to get people in TSVWG to work on and review the
>           documents (and say they will do). There needs to be people doing
>           this to ensure STD-track progression. Right now, it is hard for
>           me to judge if an RSVP implementer can interoperate using this
>           specification. If there were two independent implementations,
>           this would clearly demonstrate the implementability of a Spec.
>
>A bit later, Gorry followed up on that:
>
>    Gorry: The RSVP directorate has been contacted in the last few
>           days and I am hoping they will soon get back to me.
>           -: The old IETF ethos of "rough consensus and running code"
>           requires two implementations. This seems a good idea.
>    Gorry: I like that.
>
>     Lars: I like it too. This seems to be one way to show that the
>           specifications are readable and it can be implemented.
>
>
>