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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf