On Aug 14, 2011, at 9:24 AM, jari.ar...@piuha.net wrote: > 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
I'm not sure that I agree with that. I think that when we have an old standard that's widely used, it's important to document newly discovered limitations. But sometimes we live with the deficiencies, and sometimes we do what we can to fix the protocol without breaking compatibility. We shouldn't necessarily insist that everything meet current criteria. More generally, I don't think that advancing standards to DS should invite special scrutiny along those lines. I think we should regularly apply such scrutiny to all IETF standards, regardless of their status. If the standard no longer meets our current criteria for standardization, we should say so. But that doesn't necessarily mean we should reclassify it as Historic or otherwise take away its status. If people are still using the protocol, we can be of more service by maintaining the specification than by abandoning it. We should enumerate the known problems, identify the known fixes or workarounds, identify opportunities for new fixes that haven't been developed yet. > 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. I agree with that as you've stated it. But I think there should be a presumption that writing a new RFC is done only in extreme cases, and that when this is done, the document has to recycle at Proposed. And I'm okay in principle with editing existing RFCs and reissuing them with a new number, but I wish the new ones would have change bars. (and maybe, when rendered in HTML, other indications of specifically which text is changed). Keith
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
