Re: PS Characterization Clarified

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

 




On 2 sep. 2013, at 22:14, John C Klensin <john-ietf@xxxxxxx> wrote:



--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner
<sob@xxxxxxxxx> 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



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


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