Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)

[Job Snijders <[e-mail]>]

If values are picked for development, I'd pick them closer to 255 rather
then apply a degenerate distribution.

It is my understanding too that deprecation is temporary in that the
working group can undeprecate them in the future.

Kind regards,

Job

On Friday, 28 October 2016, John G. Scudder <[e-mail]> wrote:

> On Oct 28, 2016, at 10:26 AM, Nick Hilliard <[e-mail]
> <javascript:;>> wrote:
> >
> > Job Snijders wrote:
> >> https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00
> >
> > pls specify timeout in deprecation:
> >
> > https://www.ietf.org/mail-archive/web/idr/current/msg16576.html
>
> (Individual contributor hat)
>
> Ha, and I was just about to send a message saying I couldn't imagine
> needing to polish this document. Obviously, my imagination needs an upgrade.
>
> I'm not aware of a precedent for specifying a timeout in a deprecation, in
> fact I'm not sure what it means. I'm not sure what benefit it would bring
> either. I do see Sue's message you referenced, but the point of that, and
> also my own message around the same time, is that deprecation is one step
> in the state machine, necessary before code point reuse. I don't think we
> need to either specify either a minimum, nor a maximum, time the code point
> may spend in that state.
>
> I note that in parallel the working group has been discussing the idea of
> reusing these code points to expand the Experimental range (currently
> called "reserved for development"), so we may end up reusing them rather
> soon. In any case, deprecation is the first step toward doing that, so I
> think we may as well just get on with it with a minimum of fuss.
>
> --John
> _______________________________________________
> Idr mailing list
> [e-mail] <javascript:;>
> https://www.ietf.org/mailman/listinfo/idr
>