Keith, >> However, as with most things I don't think there are hard and fast >> rules. > > I agree that such things need to be described, but I don't think this > description should be gated on, or wait for, advancement in grade. The > errata mechanism can be used to report some kinds of vulnerabilities; > separate RFCs for others. > > Right now we have this expectation that we're going to rewrite the entire > RFC just to declare something as DS.
I do not think we currently have that expectation. I do realize that we've debated several cases and the need or lack thereof for additional changes. But in general, a document that advanced is not expected to be rewritten. At least not in my opinion. When I review -bis or -ds documents I usually focus on the rfcdiff output between the old RFC and the new draft. I also do acknowledge that we (the working groups and the IESG) have made several errors in this respect, sometimes doing more than should really have been done. But I do not think we have the expectation that all -ds documents should be rewritten. That would be wrong. What I tried to say above is that I dislike hard rules such as: - We should never require a -ds document to say additional things - We should always apply the most recent IETF approved rules (such as BCP 109 on key management) to all documents, including the -ds ones But I do agree with you that whether a separate new RFC, editing this RFC, errata or some other form of update should be decided on a case-by-case basis. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
