Re: PS Characterization Clarified

[Olaf Kolkman <[e-mail]>]

On 2 sep. 2013, at 22:14, John C Klensin <[e-mail]> wrote:

> 
> 
> --On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner
> <[e-mail]> wrote:
> 
>>> There is at least one ongoing effort right now that has the
>>> potential to reclassify a large set of Proposed Standard RFCs
>>> that form the basis of widely used technology. These types of
>>> efforts can have a relatively big effect on the standards
>>> status of the most commonly used RFCs. Do we want to do more?
>>> Can we do more?
>> 
>> seems like a quite bad idea (as Randy points out)
>> 
>> take extra effort and get some interoperability data
> 
> More than that.  Unless we want to deserve the credibility
> problems we sometimes accuse others of having, nothing should be
> a full standard, no matter how popular, unless it reflects good
> engineering practice.  I think there is more flexibility for
> Proposed Standards, especially if they come with commentary or
> applicability statements, but I believe that, in general, the
> community should consider "bad design" or "bad engineering
> practice" to fall into the "known defect" category of RFC 2026.
> If RFC 6410 requires, or even allows, that we promote things
> merely because they are popular, then I suggest there is
> something seriously wrong with it.


John,

+1

All, 

In fact, going back to the language of RFC2026 for Full (now Internet) Standard. It confirms that popularity (significant implementation) is one necessary but not sufficient criterium.

4.1.3  Internet Standard

   A specification for which significant implementation and successful
   operational experience has been obtained may be elevated to the
   Internet Standard level.  An Internet Standard (which may simply be
   referred to as a Standard) is characterized by a high degree of
   technical maturity and by a generally held belief that the specified
   protocol or service provides significant benefit to the Internet
   community.

I would hope that any concerns about technical maturity or significant benefit to the Internet community are taken into account when making the decision. If it is the case that members of the community assess that a specification lacks interoperability that should be sufficient grounds to not advance until data proofs otherwise.

And for what its worth. One of the concerns most seen are those of IPR. The stamp of Internet Standard is a confirmation of the community that any IPR on the specification can be death with, that is an important piece of information on layer 9.
 
= On a more generic note.

The reason I took initiative for this draft is mainly because I believe we need to do what we document and document what we do. As discussed in this thread the practice for the approval of PS has changed, the bar is much higher than 20 years ago. In this case it is good that we document what we do.

That shouldn't be a motivation to not do what we document: namely be serious about the maintenance of our standards. And I would hope that somehow we as a community find the energy needed to advance our specification in a way that truly assesses the requirements of RFC2026 sect 4.1.3

* significant implementation
* successful operational experience
* technical maturity
* significant benefit to the Internet community.



--Olaf