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

["Adrian Farrel" <[e-mail]>]

Hi Sue and all,

Sue, thanks for getting the ball rolling by putting pen to paper. This gives us
something concrete to work with.

I think you are trying to address two separate problems in the document. They
are both important issues that need a solution, but I think there is a problem
conflating them.

1. How to stop code point squatting in all its guises

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

IMHO you are addressing the second point well with your proposals in this draft.
That is, you are introducing a relatively low cost cross-check for allocations
from a large set of BGP registries by making them require both their current
allocation procedures *and* expert review. To complete the documentation of this
process two further things are needed:
a. Advice to the Designated Experts. This can be quite simple, but it is
intended to add some predictability and continuity to the way that DEs approach
the question of a new assignment.
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. This can be particularly lumpy because
the DEs don't get invoked until after IETF last call. It may be worth describing
this situation and explaining how the DEs should handle it.

The first point is different, and it may help to break it down into several
pieces:
i. Squatting in WG drafts
ii. Squatting in individual I-Ds
iii. Squatting outside the IETF
IDR is certainly not the only WG to have faced this problem. Solutions include:
i. Chairs must make sure it doesn't happen! Require WG I-Ds to be reposted at
once with code point values left out. Use early allocation procedures to get
real values assigned.
ii. Chairs can take some action by explaining that an I-D will not be adopted
when it contains code point values.

It may help to understand why squatting happens. Sometimes the authors are just
trying to be helpful by "suggesting" values that could be assigned - this is
addressed through firmness by the chairs, and education. Sometimes the authors
are doing an early implementation and need a code point - this is handled by
early allocation and by use of experimental code points. In some cases, the
chairs may need to help drafts be adopted into the WG and reviewed so that early
allocation can be done.

Of course, another way to handle squatting is to make it very, very easy to get
a legitimate code point. On the whole this requires a change to the allocation
policy for the registries. FCFS or Expert Review are good solutions, but
(obviously) if a registry is marked as "IETF Review" assigning an expert doesn't
help because the rules of IETF Review still have to be applied. Some people try
to fix this as "IETF Review or Expert Review" but since the lowest common
denominator will apply, this might as well just be "Expert Review". And, in case
of moving to FCFS or Expert Review, the WG has to be clear that it is willingly
giving up *any* input into the control of code point assignment.

Cheers,
Adrian


> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: 14 March 2017 14:17
> To: [e-mail]
> Cc: Jeff Haas
> Subject: Re: https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt
> 
> I think Sue has crossed the beams. (This happens frequently.)
> 
> I've long thought ER might not be a bad idea for BGP SA (and similar)
registries.
> This is not for any of the reasons Sue lists, but because we (IDR chairs) have
been
> blindsided more than once by an RFC being issued that made some kind of
> elementary gaffe. An example is the Entropy Label Capability Attribute. ADs
have
> promised us "oh we'll take care of that and make sure it never happens again",
> then it happens again. ER seems like a straightforward and already extant
piece
> of process machinery to apply to the problem of making sure IDR gets informed
> before the RFC issues.
> 
> The squatting thing is probably at the forefront of Sue's mind for obvious
> reasons, but as you say, this doesn't help at all. (Very little will help
other than
> large unconstrained code point spaces, which can be retrofitted in some cases.
Of
> course, those will lead to the problem of uncoordinated development of
> protocols and extensions that are too ossified to be changed and so will be
> presented as a fait accompli when brought to the IETF. Pay me now, pay me
later.
> 
> --John
> 
> > On Mar 14, 2017, at 7:37 AM, Adrian Farrel <[e-mail]> wrote:
> >
> > Hi,
> >
> > I probably don't mind how this pans out, but I am curious as to what problem
> > this is fixing.
> >
> > The draft says "people squatted on code points" and I don't think this
change in
> > process will stop that.
> >
> > But maybe the intention is to reduce the motivation for squatting (or to
make it
> > easier to not squat).
> >
> > Now, the document goes on to suggest that adding an expert review option
will
> > make that happen because it will "increase the pace of early allocation."
That
> > suggests that the problem is the pace of early allocation. So, why not fix
that
> > problem?
> >
> > But, looking at RFC 7120, it is up to the WG chairs to determine when early
> > allocation should be made. So how is that different from having expert
review
> > with the chairs appointed as the designated experts?
> >
> > In short, I don't think this draft is fixing anything: just fiddling.
> >
> > Adrian
> >