Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

["John G. Scudder" <[e-mail]>]

Eric,

First of all, I am going to assume we are talking about this goal (thanks, Adrian, for the nice summary):

> 2. How to stop code point allocations through the normal IANA process for "ideas
> that could use more review".


Let's consider that to be the problem statement, replacing the Abstract and Introduction in the current draft.

Sue's draft only covers registries that have what I suppose you'd call a lot of red tape to begin with -- Standards Action and IETF Review registries. The issue at hand is that although in theory these ensure plenty of review because they go through IETF last call, you may be shocked to learn that not everybody reviews every message sent to [e-mail] in a careful and timely fashion. 

It's also interesting that you bring up the question of which WG "owns" which registry. ("Furthermore, a number of the mentioned registries were not established by the IDR WG, and I don't see that the IDR WG has any standing to request changes in the registration policies of those registries.") The problem at hand arises exactly when a spec is being progressed in one WG but allocating a code point from a registry "owned" by another WG. Guess what? There is no formal concept of a WG owning a registry so there's no formal way to address this. By the same token, it also means the concept of a WG having "standing to request changes" is inoperative. Sue's draft represents an attempt at retrofitting such a concept, and again, the reason is to try to ensure sufficient review happens before it's too late.

A specific example of when this didn't happen is with the Entropy Label Capability Attribute allocated out of the BGP Path Attributes registry by RFC 6790, from the MPLS WG and later deprecated by RFC 7447 because it had a bug. IDR never touched the draft and the title of it ("The Use of Entropy Labels in MPLS Forwarding") wasn't likely to draw the eye of BGP folk. No amount of process will guarantee bugs don't slip through, but the hope is that it'd help sometimes without being onerous.

Regarding your comments about politics, I disagree but don't intend to argue the point -- I'm not going to convince you. However, all of the registries Sue identified are already SA or IETF Review, and I think Adrian nailed it when he suggested:

> b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never
> arise, but it is clear (or should be) that for a Standards Action registry, if
> there is IETF consensus for an assignment, then the DEs can warn and advise, but
> the will of the IETF takes precedence.


RFC 5226 is happily flexible in the article of what a registry policy is: "It is not required that documents use these terms; the actual requirement is that the instructions to IANA are clear and unambiguous." So if we decide that what we want is, say, Standards Action with Expert Advice (I just made that up based on Adrian's observation that this isn't actually Expert Review according to the 5226 definition), then we can do that as long as we write it up clearly.

In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting. This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course.

I think this approach would be just fine and would seem to address your morbid fears of red tape, but it requires someone to go build some new tooling (I don't even know if there's an existing tool that can be pressed into service or if we're talking about an entirely new thing), whereas the registry policy proposal uses "tooling" that already exists.

--John