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

["James M. Polk" <[e-mail]>]

At 11:21 AM 10/27/2010, James M. Polk wrote:
>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

I inadvertently left out the word "suggesting" right here in the sentence.

>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.
>>
>>