motivations (was: Re: draft-housley-two-maturity-levels-00)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 Russ,

Thank you for bringing this topic full circle.  Having considered this
topic for a long time, and having lead a cleanup around old standards in
newtrk, I share the following thoughts for your consideration.

In concurring in part with what Bernard and Mike wrote, the basic
question I ask, in several parts, is whether standards maturity levels
have been overtaken by events or time?  For each level above PS, a
substantial amount of work must go into advancement, perhaps without a
single line of code actually being written or changed by implementers. 
This then leads to a question of motivations.  What are the motivations
for the IESG, the IETF, and for individual implementers?  Traditionally
for the IETF and IESG, the motivation was meant to be a signal to the
market that a standard won't change out from underneath the developer.

Question #1: Is such a signal needed today?  If we look at the 1694
Proposed Standards, are we seeing a lack of implementation due to lack
of stability?  I would claim that there are quite a number of examples
to the contrary (but see below).

Question #2: Is the signal actually accurate?  Is there any reason for a
developer to believe that the day after a "mature" standard is
announced, a new Internet Draft won't in some way obsolete that work? 
What does history say about this effort? 

Question #3: What does such a signal say to the IETF?  I know of at
least one case where work was not permitted in the IETF precisely
because a FULL STANDARD was said to need soak time.  It was SNMP, and
the work that was not permitted at the time was what would later become
ISMS.

Question #4:  Is there a market advantage gained by an implementer
working to advance a specification's maturity?  If there is none, then
why would an implementer participate?  If there *is* a market advantage,
is that something a standards organization wants?  Might ossification of
a standard retard innovation by discouraging extensions or changes?

Question #5:  Are these the correct questions, and are there others that
should be asked?

I do not mean to answer these research questions here, but I claim that
that they should be answered, perhaps with some academic rigor, and may
be a worth subject for the economics and policy research group that
Aaron is considering.

Referring to SM's and Dave's messages, judging maturity based on
industry-wide acceptance requires a similar analysis, but with an added
twist: the grey areas of industry acceptance make these sorts of
decisions for the IESG rather difficult.  Having gone through the
effort, it was clear to me that there have been some losers, and I think
we can all spot some winners that remain at Proposed.

Eliot

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]