On Wed, Mar 16, 2011 at 6:13 AM, Dave CROCKER <dhc2(_at_)dcrocker(_dot_)net>
wrote:
On 3/14/2011 2:05 PM, Brian E Carpenter wrote:
2) More substantively,
"Any protocol or service that is currently at the Draft Standard
maturity level may be reclassified as an Internet Standard as soon as
the criteria in Section 2.2 are satisfied. This reclassification is
accomplished by submitting a request to the IESG along with a
description of the implementation and operational experience. "
I'm a bit concerned that this doesn't scale, and we will be left
with a long tail of DS documents that end up in limbo. One way to avoid
this is to encourage bulk reclassifications (rather like we did a bulk
declassification in RFC 4450). Another way is to define a sunset date,
e.g.
Any documents that are still classified as Draft Standard two years
after the publication of this RFC will be automatically downgraded
to Proposed Standard.
Brian,
Certainly a reasonable concern. However...
1. While the accounting ugliness of leaving these untouched is obvious, I
am less clear about the practical trouble they cause. We should gain some
public agreement that this is seriousness enough to worry about, and why.
2. Automatic reclassification strikes me as dangerous and likely to have
serious unintended consequences. I believe we do not have a history of
having done anything like this, in spite of our rules, except for aging out
I-Ds.
3. Your's specific proposal assumes ready availability of workers for
documents that are used. In fact, the folks who use specs are often far
removed from the IETF and neither aware of IETF activities nor available to
contribute to them. This is an example of a downside likely to downgrade
docs inappropriately, IMO.
Alas, I don't have a constructive, alternative suggestion.
There's a fairly obvious alternative, which is to <shrug> about the widespread
deployment rule and promote all existing DS automatically to Internet Standard.
That wouldn't shock me - and it would be a lot less work for everybody.
We could still require widespread deployment for future documents.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf