Re: two independent implementations (Re: draft-housley-two-maturity-levels)
At 11:21 AM 10/27/2010, James M. Polk wrote:
At 02:16 AM 10/27/2010, Lars Eggert wrote:
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?
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.
Ietf mailing list