Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

[Jeffrey Haas <[e-mail]>]

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> The author has asked for the WG to adopt  draft-snijders-idr-deprecate-30-31-129. 
> 
> If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead.

I have a few points to raise here:
1. Do we actually need a draft published to request IANA to block out
allocation of these code points?  If so, we're going to end up with a number
of trivial drafts for these corrective actions.  I'm interested in hearing
the IESG's opinion on this point.

If we do need a draft, this draft is as fine as any.  Hopefully we don't
need one.

2. Much as it's tempting to try to use this process to try to be the clue
hammer and "punish" people for grabbing code points, you burn enough bridges
you eventually run out of wood.

We have a few issues code shipping with such use suggest:

2a. Some of these things are features in use.  If so, they're just going to
have to get a different official code point.  

IMO, the right answer here is to push the implementors to get their
registrations in order and officially request them.  The penalty on *them*
is the potential that someone else has already collided with them due to
different squatting.

2b. Some of these things are early implementations that are against drafts
that aren't fully mature.  This means there will be versioning issues.
Either the code point gets re-used and deals with the versioning problem or
the code point needs deprecation.

And even then, the fact that there's an early implementation means that
eventually a code point is needed.

---

It seems to me what is needed is some work to classify such early
deployments as 2a or 2b.  2a just involves getting some administrative
issues cleared.  2b means we should discuss how do we "clean" a code point
sooner than later.

Final observation:  Some of this is messy due to scope propagation issues of
internal features.  This is another wake-up to deal with that propblem.

-- Jeff