Russ
I strongly support this approach.
In particular I think the downward ref relaxation is of great value as
chair of WG with with 30+ RFC's at PS and advancing them in order or
RFC's up the standards track vs. advancing the ones that are important
will hopefully be the happy consequence of a change like this.
Olafur
On 21/06/2010 9:39 AM, Russ Housley wrote:
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf