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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf