Yaron: > In general, I think this is a good idea. It might succeed in reviving > the notion of formal interoperability reports. A few comments though: > > - Sec. 2 mentions that the criteria for Proposed Standard will not > change. But the preceding section just described that our criteria (or > processes) for publication are too onerous. So do we not address what's > mentioned as a leading motivation for this change? What a meant here is that the requirements in RFC 2026 for Proposed Standard do not change. With the opportunity for a "second bite at the apple", I hope that the escelation that has happened over the decades can be pushed back. > - I think the name "Interoperable Standard" is unfortunate. First, it's > a mouthful. And second, it implies that whereas we didn't care about > interoperability before, now we suddenly do. As an analogy, suppose we > had "Proposed Standard" and "Secure Standard". Instead, I think "Full > Standard" or "IETF Standard" would be better names. After all, people > are looking to the IETF for standards. I am not wed to the name. I'd prefer "Internet Standard" above the names you suggest. > - This is not to criticize the draft, but I am really wondering: at > IPsecME we are close to publishing IKEv2-bis, and we went to great > lengths to make it as faithful as possible to the original IKEv2 (RFC > 4306), so that implementations that are compliant don't suddenly become > non-compliant. Suppose we were to advance this large and complex > protocol to the 2nd maturity level, is there a manageable process to > eliminate features from the protocol (because there are no two > implementations that implement said features) without worrying that some > implementations out there have become non-compliant overnight? We have always published a "bis" RFC that removes the features. These RFCs ought to explain the reason for the feature removal. Support of an obsoleted feature does not have to make an implementation non-conformant. For example, "legacy" features could be documented in an informative appendix with a warning about the consequences on interoperability if they are supported. Russ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf