John C Klensin wrote: > But I also agree with part of Adrian's comments. Our vocabulary > for describing these things may be sub-optimal and that may have > gotten in our way. Perhaps something more along the lines of > "approved standard", "interoperable standard", and "verified > standard" would serve us better than PS/ DS/ Full. But a > different piece of vocabulary might be equally important: > perhaps we should be talking about "recognizing" something at a > standard at a particular level and not "advancing" it. > > I also believe that part of the problem involves what amounts to > a positive feedback loop: because few documents are advanced > past PS, the IESG feels obligated to impose requirements on > approval at PS that go far beyond what is required by 2026. > Once documents are polished to a high luster, at the cost of > considerable time, for PS, there is little incentive to advance > them and, worse, even more impressive requirements are imposed > in practice at DS and Full, possibly to give them some > distinction beyond Proposed. If we could get back to treating > Proposed much as the IEEE used to treat "Draft Standard for > Trial Use" -- "no known technical defects" in the protocol and > documentation that was not required to be more than adequate to > explain the idea -- then we might be able to get things into > Proposed more quickly and have incentive for document revision > and advancement (sic) for those ideas that actually turned out > to get traction in practice. I think John's hit the nail right on the head here. I would like to go a bit further and say that it's long past time to abandon the name "RFC" altogether. While I understand and respect the historical underpinnings of the term I agree with those who have commented that for most of the world "an RFC is an RFC is an RFC" and our fine distinctions like "Experimental," "Informational" etc. are lost. My suggestion would be to name the documents what they are, and to come up with new terms for the documents that reflect the evolution of the process. In the standards track area I think names like the ones John proposed are good, I personally would s/interoperable/deployed/ but that's a detail that can be tweaked later, as can names for some of the other categories of things that are all called RFCs now. Anyone else think that clarifying the naming scheme is a good idea? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf