On Aug 14, 2011, at 5:49 AM, jari(_dot_)arkko(_at_)piuha(_dot_)net 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf