On Wed, Mar 16, 2011 at 6:13 AM, Dave CROCKER <d...@dcrocker.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf