SM: > From Section 2.1: > > "no existing published requirements are relaxed". > > Are these published requirements BCPs? Yes. > From Section 2.2: > > 'This maturity level is a merger of Draft Standard and Standard as > specified in RFC 2026 [1]. The chosen name avoids confusion between > "Draft Standard" and "Internet-Draft".' > > Shouldn't that be "Internet Standard" instead of "Standard"? Look at RFC 2026. The three level defined there are Proposed Standard, Draft Standard, and Standard. The draft-housley-two-maturity-levels proposes two levels: Proposed Standard and Internet Standard. > "The request for reclassification is sent to the IESG along with an > explanation of how the criteria have been met. > The criteria are: > > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > > (3) There are no unused features in the specification that greatly > increase implementation complexity." > > The document that has been the subject of innumerable messages highlights how difficult it can be to reclassify a RFC. Moreover, it amplified the divide between application folks and operators. The IESG could have used the review clause from RFC 2026 and: > > (i) requested an implementation report from the people in favor of the > proposed standard; and > > (ii) a statement about deployment to determine whether there are operational > issues that have to be addressed. > > I don't know whether application folks and operators agree that cross-area requires mutual understanding. > > The creation of interoperable protocol implementations requires clear specifications. Interoperability does not mean that the protocol would not have unintended effects on the network. That is where operational experience comes in. It can serve as valuable input to improve a specification. For what it is worth, there approximately 75 implementation reports have been submitted since 1996. I am well aware of the implementation reports. The premise here is that the protocol specification is "good enough" there are at least two interoperable implementations and the protocol is deployed widely. The implementation report would become optional. > A two-step maturity level folds the two different classes of issues into one. Quoting RFC 5657, which this draft unfortunately does not reference: > > "Moving documents along the standards track can be an important signal > to the user and implementor communities, and the process of > submitting a standard for advancement can help improve that standard > or the quality of implementations that participate." > > During a discussion on another mailing list, it has been mentioned that such an effort has a cost. Lumping all the issues together can only increase that cost. People are not doing many implementation reports. As you say above, there are only about 75 of them. How many protocols are documented in RFCs? That is a very low percentage in my view. So, I see the cost quite differently. Most protocols are published as Proposed Standards, and they are never advanced. I'm seeking a process where implementation and deployment experience actually improves the protocol specifications. Today, that rarely happens, and when it does, the document recycles at Proposed Standard and the reader does not know whether it happened or not. > Strangely, this draft argues for measuring "interoperability through widespread deployment of multiple implementations from different code bases". It will be more difficult to remove features once implementations are widely deployed. Keeping the feature fight within the Draft Standard discussion can reduce the level of controversy at the last step. As a side note, it would be less costly if feature evaluation was based on implementations instead of what people would like to keep (only one implementation of a feature). This is an argument for the status quo. We have decades of experience with that not working. That is essentially an argument for a single maturity level; that is how the process is really working today. > Once a Proposed Standard is published, it is expected that people will go and write code, if they have not done so yet, and evaluate whether their implementation can interoperate with other implementations. I don't see anything in this draft that encourages that. Of course that is what we want. Even better if the running code is used to make decisions before the protocol become a Proposed Standard. > In the RFC 5000 range, there are 7 Internet Standards, 13 Draft Standards and 537 Proposed Standards. One of the arguments for this draft is that it reduces the number of IESG evaluations, and other review cycles, from three to two. Basically, this draft is to adjust the environment so that the IESG can review everything. It does not reduce the barrier of "intended proposed standards" to the RFC 2026 level. It does not offer any incentive to advance document along the Standards Track. This document is not about IESG review time, except for the elimination of the requirement for annual reviews which are not done anyway. If that is what you get from the document, then I have done a very poor job in writing it. That is not the point at all. Russ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf