On Aug 14, 2011, at 5:49 AM, jari.arkko@xxxxxxxxx wrote: >> I pretty much agree, although one form of discuss might be >> reasonable: "This document needs to be recycled at Proposed >> Standard because of the following *observed* interoperability >> problem:...". >> >> In other words, once we have got this BCP out (soon, please), >> the IESG should update the DISCUSS criteria specifically to >> narrow them for the PS->IS transition. > > I also pretty much agree, and the IESG discuss criteria document > (http://www.ietf.org/iesg/statement/discuss-criteria.html) would certainly > benefit from a respin to provide guidelines for -bis documents and > documents advancing further. > > However, as with most things I don't think there are hard and fast rules. > I can imagine a very old RFC being respin or advancing where I'd want some > rework. For instance, a vulnerability that was discovered after the > orginal RFC should be described, perhaps even dealt with somehow. 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. That is a lot of work, opens up a huge can of worms, imposes a large barrier to the interop testing that we want to encourage, and sometimes introduces confusion by subtly changing the original specification. Old standards do need maintenance. Our process doesn't really account for that. It has this fiction that once a protocol gets to Full Standard, it's good forever - or that it needs a complete and very tedious rewrite and recycle from Proposed. And the current process doesn't (in practice) document the shifting applicability of standards over time. I'd like to see some sort of changes to the process that recognize the need to periodically review and occasionally maintain old standards, update their applicability without changing the text of the document, and that allows for incremental updating (with change bars etc.) without changing the basic form of the text. Of course the changes do need to be reviewed, and IESG is already over-worked. Maybe we need review groups that are analogous to working groups, and a separate supervisory board for reviews. The review groups and board would be limited as to what they could do with a standard - e.g. clarify text where ambiguity had been identified, document new vulnerabilities (whether security, scaling, whatever), note limitations in applicability. They'd have no power to add new features, or maybe only when the feature was narrowly tailored to fix a documented problem with the older spec. This might even lighten IESG's load a bit because a few existing WGs could be changed to review groups. And hopefully the review supervisory board's load would be lighter than IESG's so it wouldn't be so hard to recruit suitable candidates for it. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf