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

["Susan Hares" <[e-mail]>]

John: 

The NM/OPS has found the tool filter of Yang model tests goes well with the
YANG Doctor's review. 

Sue 

-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of John G. Scudder
Sent: Wednesday, March 22, 2017 2:37 PM
To: Eric Rosen
Cc: Susan Hares; [e-mail]
Subject: Re: [Idr] Thoughts on
https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

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
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr