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

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

Adrian:

Thank you for this analysis.  This proposal was aimed at #2.  For the
education in #1, see Jeff Haas' slides from the last IETF.   Your comments
on what Chair's need to do are helpful comments.  For getting early
allocations,  I still believe the WG needs to be in the process.  I agree we
need to work on "why" people squat.  For this, I hope we will have a good
discussion on IDR and Grow  - at the very least. 

Sue 
-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Tuesday, March 14, 2017 11:39 AM
To: 'Susan Hares'
Cc: [e-mail]
Subject: Thoughts on
https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

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
> >