On 2 sep. 2013, at 22:14, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner
<sob(_at_)sobco(_dot_)com> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail