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