On Oct 4, 2010, at 4:16 PM, Barry Leiba wrote:
A periodic call for comments, say at 2 and 5 years out, with those
judged to be still useful moving up the ladder,
for example?
I understand that "objection based processing" was not the most polite
way to word this in my draft,
and I'm sufficiently chastened to change it in the next version. But
I think any system we base on a periodic
assessment like the above has to have a default of "advance". The
current Proposed standards
get a lot of scrutiny and generally are pretty good. If we don't do
"default advance", we are adding
friction to the common case, where they should move forward.
While this is true as far as it goes, I'd like to point out a good
example of where "the common case" may be less common than we'd like
to think.
ACAP, RFC 2244, is a Proposed Standard put out in 1997. There's a
core of us who think it's a good protocol and a useful one, but it's
had very scanty implementation. At this point, even most of its
champions think it might as well go to "Historic".
On the other hand, it suffers far more from apathy than from
antagonism, and should it have routinely come up for any sort of
review that had a default answer of "advance", it would almost
certainly have been advanced. I doubt there would have been people
who really cared to fight to block it because hardly anyone uses it.
None of us ever tried to move it along the track because we knew
(know) that there's not much point.
There's no doubt in my mind that, much as I like it, ACAP should not
be at a higher current maturity level than PS. There's some value in
saying that there have to be people who have the energy to push a rock
at least a little way up a hill in order to make something advance, to
show that there's some critical mass of support and implementation.
Otherwise, we may wind up with a bunch of little known and lesser
deployed "pet rocks" (to strain a metaphor) that get advanced by
default, providing little service or benefit to the Internet.
I think part of the problem is that our current "maturity" labeling scheme
conflates several things:
- quality of the protocol itself (is the design good and without significant
known flaws relative to its intended/expected use?)
- quality of the specification (is it written clearly and precisely enough to
encourage interoperability?)
- currency of the specification (does the written specification still reflect
current and/or desirable practice?)
- applicability of the protocol (how broadly should it be used?)
- initial/continued acceptance/deployment of the protocol
...which is why, instead of "advancing in grade" from PS to DS to FS, I'd like
to see a periodic re-evaluation of the last three. There are protocols today
which are Full Standard for which the specifications are not being
well-maintained and which don't reflect good current practice. There are also
protocols which are Proposed Standard for which the specifications are
reasonably current and reflective of good practice. There's a disconnect
between our labeling of these standards and their "goodness" to the community,
and that harms IETF's credibility.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf