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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 15:38:43 -0000

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:[email-masked]]
> Sent: 14 March 2017 14:17
> To: [email-masked]
> 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 <[email-masked]> 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
> >

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 14 Mar 2017 13:18:26 -0400

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:[email-masked]] 
Sent: Tuesday, March 14, 2017 11:39 AM
To: 'Susan Hares'
Cc: [email-masked]
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.

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

> Subject: Re: 
> https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt
> 
registries.
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
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.
> > I probably don't mind how this pans out, but I am curious as to what 
> > problem this is fixing.
> >
change in
make it
will
That
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

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 14 Mar 2017 15:38:12 -0400

I don't think we need any more procedural hurdles that will slow down 
the allocation process or that will introduce more politics into it.

The draft does not seem to be a solution to any problem, it just adds 
process and politics.  It claims to have the goal of "increasing the 
pace of early allocation", and proposes to do this by requiring 
allocations to be approved by a committee of WG chairs or other 
designated "experts".  It neglects to say how having more committees 
will increase the pace.

No doubt the designated experts will make their decisions "soon", as 
that term is defined in draft-farrel-soon.

Adoption of this draft will result in more squatting rather than less.

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.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Mar 2017 21:34:32 +0100

I very much agree with Eric here.

All what needs to be done to prevent squatting is a public wiki page in
IETF (across WGs) with pool of available BGP attribute code points as well
as AFI/SAFIs where whoever has a draft and is implementing it ahead of IETF
politics takes next available code and links it with a draft name. Then she
or he may come to WG with proven implementation at hand.

By default considering how fast IETF moves such self registration could be
valid for 5 years. After that either the spec is dead and it is ok to free
up the code or draft becomes RFC. Submitter can free up the code earlier
too.

All committees, designated experts, tiger/design teams will just have
opposite effect and granted will scare folks who need to implement
something for their internal use or for their dedicated customers resulting
in much more squatting. Does anyone really believes that if "expert" tells
 "NO" then the given implementation will get abandoned ?

The same should apply to other protocols .. however BGP is the lowest
hanging fruit so one could start with that.

On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen <[email-masked]> wrote:

> I don't think we need any more procedural hurdles that will slow down the
> allocation process or that will introduce more politics into it.
>
> process and politics.  It claims to have the goal of "increasing the pace
> of early allocation", and proposes to do this by requiring allocations to
> be approved by a committee of WG chairs or other designated "experts".  It
> neglects to say how having more committees will increase the pace.
>
> No doubt the designated experts will make their decisions "soon", as that
> term is defined in draft-farrel-soon.
>
> 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.
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Mar 2017 16:44:14 -0400

> or he may come to WG with proven implementation at hand.

In praise of IANA, their FCFS turnaround is quite fast.  They satisfy all of
the necessary properties above.

No need for wiki here.

-- Jeff (otherwise a wiki fan)

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Mar 2017 21:48:10 +0100

It's not that IANA is slow ... it's the process that get's you to IANA is a
bottleneck.

Can anyone submits a draft to IANA to get code point without any IETF
sponsorship ?

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Mar 2017 17:03:05 -0400

> Can anyone submits a draft to IANA to get code point without any IETF

FCFS is FCFS. 

If you wanted to submit a draft-raszuk-waste-extcomm-code-point, you could
likely prove this, but I suspect IANA wouldn't be happy and would at least
press you "um, this doesn't look like it's going to be around long...."

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 11:55:58 -0400

Eric: 

Politics: I do not know how this introduces politics - since it is just the
WG chairs.  The WG chairs for BGP related groups are very collaborative.  If
they are not collaborative, the ADs can work with or replace the WG chairs.

How does it speed up things?  It provides 8 designated experts which means
IANA does not have to chase down a few people (2-3).   This is the most
often reason for IANA slow-downs (AFAIK).  The collaborative chairs can
decide on a rotation for a designated person to check up with other chairs.
The new datatracker review process could automate that process. If you think
this should have a time limit (for example - 2 weeks), I agree.  I also
believe it should run concurrent with other processes.  This process should
start after the AD review considers document worthy and it MUST start no
later than IETF LC (2 weeks).   With these additions, I do not think it will
slow down the process. 

Have I responded to all your concerns?  If you think these mitigate the
problems, I will provide a revision to the draft that specifies these
changes. 

Sue 

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 3:38 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Thoughts on

The draft does not seem to be a solution to any problem, it just adds
process and politics.  It claims to have the goal of "increasing the pace of
early allocation", and proposes to do this by requiring allocations to be
approved by a committee of WG chairs or other designated "experts".  It
neglects to say how having more committees will increase the pace.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 12:04:56 -0400

Robert: 

Please see my post to Eric responding to politics and delay.  

What you are describing is a FCFS.  Rather than a wiki, why not IANA?  IANA can provide and maintains these numbers.  IANA’s response time on FCFS allocations is quick.   If you believe a FCFS is appropriate for BGP attributes and AFI/SAFs,  I encourage you to write a draft on that topic.  

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 14, 2017 4:35 PM
To: Eric C Rosen
Cc: Susan Hares; idr wg
Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

All what needs to be done to prevent squatting is a public wiki page in IETF (across WGs) with pool of available BGP attribute code points as well as AFI/SAFIs where whoever has a draft and is implementing it ahead of IETF politics takes next available code and links it with a draft name. Then she or he may come to WG with proven implementation at hand.

By default considering how fast IETF moves such self registration could be valid for 5 years. After that either the spec is dead and it is ok to free up the code or draft becomes RFC. Submitter can free up the code earlier too. 

All committees, designated experts, tiger/design teams will just have opposite effect and granted will scare folks who need to implement something for their internal use or for their dedicated customers resulting in much more squatting. Does anyone really believes that if "expert" tells  "NO" then the given implementation will get abandoned ? 

The same should apply to other protocols .. however BGP is the lowest hanging fruit so one could start with that.

I don't think we need any more procedural hurdles that will slow down the allocation process or that will introduce more politics into it.

The draft does not seem to be a solution to any problem, it just adds process and politics.  It claims to have the goal of "increasing the pace of early allocation", and proposes to do this by requiring allocations to be approved by a committee of WG chairs or other designated "experts".  It neglects to say how having more committees will increase the pace.

No doubt the designated experts will make their decisions "soon", as that term is defined in draft-farrel-soon.

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.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 21 Mar 2017 16:53:35 -0400

On 3/21/2017 11:55 AM, Susan Hares wrote:
>
> Eric:
>
> *Politics:* I do not know how this introduces politics - since it is 
> just the WG chairs. The WG chairs for BGP related groups are very 
> collaborative.
>

And they would never dream of trying to manipulate the process in order 
to slow down the work of a competitor!  Absolutely unheard of.

A committee with no politics?  That would be a first.

> If they are not collaborative, the ADs can work with or replace the WG 
> chairs.
>

Oh, no politics there either ;-) And we know how quickly things happen 
when the ADs have to "work with or replace" the chairs.

> *How does it speed up things?*  It provides 8 designated experts which 
> means IANA does not have to chase down a few people (2-3).
>

Currently, with no designated experts, IANA does not have to chase down 
anyone.  Requiring additional approvals can only slow things down, not 
speed them up.

> This is the most often reason for IANA slow-downs (AFAIK).  The 
> collaborative chairs can decide on a rotation for a designated person 
> to check up with other chairs.
>

Egad, more process.

>
> Have I responded to all your concerns?
>

Not at all.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 21 Mar 2017 15:26:27 -0700

+1

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 22 Mar 2017 14:36:32 -0400

Eric,

> 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 [email-masked] 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:

> 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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Mar 2017 17:44:23 -0400

Eric: 

What I summarize from your note is the following: 

1)       You do not feel WG chairs or ADs are collaborative in the IETF
professional society even though the IETF runs on rough consensus and
running code.   You feel WG chairs and ADs are motivated by commercial
reasons before the altruism of the IETF professional ideals.   

2)      You want a BGP attribute name-space without any oversight, even
though squatting brought attribute conflict that lead us to this point. 

3)      "egad process" is the depth of your understanding on the IANA
reviews.  

Wow!  An anarchist in a standards society with a low opinion of moral of WG
chairs and ADs.  

Thank you for bringing an enjoyable moment  into my day.  

Sue 

Sent: Tuesday, March 21, 2017 4:54 PM

Eric: 

Politics: I do not know how this introduces politics - since it is just the
WG chairs. The WG chairs for BGP related groups are very collaborative.  

And they would never dream of trying to manipulate the process in order to
slow down the work of a competitor!  Absolutely unheard of.

Oh, no politics there either ;-) And we know how quickly things happen when
the ADs have to "work with or replace" the chairs.

How does it speed up things?  It provides 8 designated experts which means
IANA does not have to chase down a few people (2-3).   

Currently, with no designated experts, IANA does not have to chase down
anyone.  Requiring additional approvals can only slow things down, not speed
them up.

This is the most often reason for IANA slow-downs (AFAIK).  The
collaborative chairs can decide on a rotation for a designated person to
check up with other chairs.  

Egad, more process.

Not at all.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Mar 2017 17:48:17 -0400

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:[email-masked]] On Behalf Of John G. Scudder
Sent: Wednesday, March 22, 2017 2:37 PM
To: Eric Rosen
Cc: Susan Hares; [email-masked]
Subject: Re: [Idr] Thoughts on

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 [email-masked] 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

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 23 Mar 2017 13:29:12 -0400

On 3/22/2017 2:36 PM, John G. Scudder wrote:
> I think Adrian nailed it when he suggested:
>

According to the proposal under consideration, the DEs are the same 
people who judge whether there is IETF consensus.  The conflict of 
interest is evident.

> the reason is to try to ensure sufficient review happens before it's too late.

I'm not opposed to additional review, but that has nothing to do with 
the codepoint allocation process.  Presumably it is already the job of 
the WG chairs and/or document shepherds to obtain an adequate level of 
review.

> the concept of a WG having "standing to request changes" is inoperative

I'm looking forward to the day when you can't get a codepoint in any 
registry without the approval of the security and the operations ADs ;-)

> In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting.

That's an interesting suggestion, but has to be used carefully.  If 
someone is squatting on a codepoint, they should be encouraged to tell 
the rest of us that they are doing so.  Encouraging them to keep it a 
secret (to avoid being tagged by idnits) would be a strange way to 
encourage interoperability.

I also think that document shepherds should be on the lookout for cases 
where drafts specify codepoints or flags for new stuff without 
requesting the necessary registries to be set up.

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

This proposal makes sense.  It encourages more review without giving 
dictatorial powers to a committee of WG chairs.

> your morbid fears of red tape

I've seen many cases where IETF politicians wield red tape as a weapon; 
some do so quite expertly.  Ultimately all type fields will be 
two-octets long with FCFS registration; that's the ultimate solution to 
this particular red tape problem.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 23 Mar 2017 13:42:19 -0400

On 3/22/2017 5:44 PM, Susan Hares wrote:
> You feel WG chairs and ADs are motivated by commercial reasons before 
> the altruism of the IETF professional ideals. 

This doesn't apply to all WG chairs and ADs at all times, but it 
certainly happens frequently.

> You want a BGP attribute name-space without any oversight, even though 
> squatting brought attribute conflict that lead us to this point. 

Squatting is the use of unregistered codepoints.  I do not support the 
use of unregistered codepoints.  I think it should be easy to register 
codepoints, and making it easy will prevent squatting. Anything that 
makes registration more difficult will encourage more squatting.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Mar 2017 13:46:39 -0400

Eric: 

Thank you for your return comments with helpful suggestions: 

1)      IETF consensus trumps  DE opinion -   If you are suggesting that the
WG chair(s) that sponsored a draft should not be the Designated Expert.
Good idea.

2)      Adequate review -  If you wish it to be a single working group
assigning BGP code points, the WG chair/document shepherd method works.  By
this comment, we would need to select one WG to approve standardization of
BGP code points.  My proposal at IETF 97 was that IDR was such a WG since
BGP base specifications (e.g., RFC4271) were started there.  My alternate
proposal of shared responsibility among the BGP-focused chairs is the
bgp-registries. 

3)      On reviewing Shepherd's work - sounds like you would be a useful
reviewer for documents.  Please volunteer.  

4)      On code point squatting, operators had real problems with the
current situation.   Job said "automatic checks on drafts",  Sue said "IETF
Standard + DE of BGP chairs where IETF Consensus wins" - Got any alternate
solutions.  Got any alternate suggestions? 

Sue Hares 

From: Eric C Rosen [mailto:[email-masked]] 
Sent: Thursday, March 23, 2017 1:29 PM
To: John G. Scudder
Cc: Susan Hares; Adrian Farrel; [email-masked]
Subject: Re: [Idr] Thoughts on
https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

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.

According to the proposal under consideration, the DEs are the same people
who judge whether there is IETF consensus.  The conflict of interest is
evident.

the reason is to try to ensure sufficient review happens before it's too
late.

I'm not opposed to additional review, but that has nothing to do with the
codepoint allocation process.  Presumably it is already the job of the WG
chairs and/or document shepherds to obtain an adequate level of review.

In parallel, Job Snijders made a useful suggestion that idnits maybe should
be on the lookout for code point squatting.

That's an interesting suggestion, but has to be used carefully.  If someone
is squatting on a codepoint, they should be encouraged to tell the rest of
us that they are doing so.  Encouraging them to keep it a secret (to avoid
being tagged by idnits) would be a strange way to encourage
interoperability.

I also think that document shepherds should be on the lookout for cases
where drafts specify codepoints or flags for new stuff without requesting
the necessary registries to be set up.

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've seen many cases where IETF politicians wield red tape as a weapon; some
do so quite expertly.  Ultimately all type fields will be two-octets long
with FCFS registration; that's the ultimate solution to this particular red
tape problem.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 23 Mar 2017 14:10:53 -0400

> solutions.  Got any alternate suggestions? 

Wearing my work process hat, the issue is flagging when something needs more
eyes.  

IETF process already gives us the necessary voice in how stuff works for
allocation, I think.  It's less we need a panel of designated experts, it's
more that once something has been noticed, many voices will suggest doing
the right thing.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Mar 2017 14:13:07 -0400

Jeff: 

Yes!

- If flagging for more eye review is the case, then Job's suggestion is the
way forward.  It works for most YANG modules. 
- If having the expertise to review the "flag" is the issue,  1 WG being in
charge of the situation will suffice with the current setup. 
- if cross-review in all BGP working group is issue - then try my registries
proposal + IETF consensus. 
- if distrust of a single answer from WG shepherd, WG chair or set of WG
chairs - this draft + Eric's suggestion for who can review. 

If we can define the largest concern(s), let's we could start with that
solution.  

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, March 23, 2017 2:11 PM
To: Susan Hares
Cc: 'Eric C Rosen'; 'John G. Scudder'; [email-masked]
Subject: Re: [Idr] Thoughts on

On Thu, Mar 23, 2017 at 01:46:39PM -0400, Susan Hares wrote:
> Standard + DE of BGP chairs where IETF Consensus wins" - Got any 
> alternate solutions.  Got any alternate suggestions?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Mar 2017 14:35:19 -0400

Sue,

Automated checks on drafts means "*no self documented allocation*".

Folks who are implementing things even will continue to do "s*elf
undocumented allocations" *or are going to be permitted to get next code
point and proceed with implementation without any politics and reviews.

John said that your draft targets only standard action and IETF standards
track final allocations where document goes via WG last call.

But in my opinion the genesis of squatting is not at that point in time
scale. It happens much earlier where an idea in the draft if facing early
implementation. Jeff suggested to send such draft to IANA for early
allocation individually but it will be seen in bad light.

So with all of the above we still have no way to get codepoints for early
implementations without being stuck with reviews. And implementations are
not even used to jusitfy acceptance to become a WG document in IDR ....

Cheers,
r.

On Thu, Mar 23, 2017 at 1:46 PM, Susan Hares <[email-masked]> wrote:

> 1)      IETF consensus trumps  DE opinion -   If you are suggesting that
> the WG chair(s) that sponsored a draft should not be the Designated
> Expert.  Good idea.
>
> 2)      Adequate review –  If you wish it to be a single working group
> 3)      On reviewing Shepherd’s work – sounds like you would be a useful
> current situation.   Job said “automatic checks on drafts”,  Sue said “IETF
> Standard + DE of BGP chairs where IETF Consensus wins” – Got any alternate
> *From:* Eric C Rosen [mailto:[email-masked]]
> *Sent:* Thursday, March 23, 2017 1:29 PM
> *To:* John G. Scudder
> *Cc:* Susan Hares; Adrian Farrel; [email-masked]
> *Subject:* Re: [Idr] Thoughts on https://www.ietf.org/id/draft-
> hares-idr-bgp-registries-01.txt
>
>
>
> someone is squatting on a codepoint, they should be encouraged to tell the
> rest of us that they are doing so.  Encouraging them to keep it a secret
> (to avoid being tagged by idnits) would be a strange way to encourage
> interoperability.
>
> some do so quite expertly.  Ultimately all type fields will be two-octets
> long with FCFS registration; that's the ultimate solution to this
> particular red tape problem.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 23 Mar 2017 14:46:09 -0400

> way forward.  It works for most YANG modules. 

As I noted off-list to Job, pattern matching works great when you have a
pattern that can catch it.  Better than nothing, especially if we end up
with good boilerplate text for allocations.  (It might be worth having a
chat with IANA about that.)

> chairs - this draft + Eric's suggestion for who can review. 

Mostly, I think once an issue is flagged, all eyes need to be pulled to one
place.  For the registries in question, IDR@ietf is probably fine, as long
as we reach out.

While I share some of Eric's dislike of process, I don't quite share his
paranoia about process blockers.  When things go awry anyway, the best we
have in process is the appeals process.  If we've reached that point, speed
is doomed anyway.

> If we can define the largest concern(s), let's we could start with that

I'd suggest finding a way to flag stuff is appropriate.  Nits search is one.
Allowing chairs to prod a button in datatracker that says cross-WG review is
needed might be another.  I suspect this may make good wgchairs discussion.

-- Jeff

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 23 Mar 2017 14:51:03 -0400

On 3/23/2017 1:46 PM, Susan Hares wrote:
>
> 1)IETF consensus trumps  DE opinion -   If you are suggesting that the 

That was not my suggestion.

> 2)Adequate review –  If you wish it to be a single working group 
> assigning BGP code points,
>

That was not my suggestion either.

> 4)On code point squatting, operators had real problems with the 
> current situation.   Job said “automatic checks on drafts”, Sue said 
> “IETF Standard + DE of BGP chairs where IETF Consensus wins”
>

My point is that neither of these solutions will solve the problem. They 
simply create more process and just make the problem worse.

The problem is real, the solutions are bogus.

---

From: Enke Chen <[email-masked]>
Date: Thu, 23 Mar 2017 12:01:11 -0700

Eric,

On 3/23/17 10:29 AM, Eric C Rosen wrote:
[snip]

> Ultimately all type fields will be two-octets long with FCFS registration; that's the
> ultimate solution to this particular red tape problem.

Not only the type fields, but also the length fields in TLVs.

Given the processing power and memory, there is hardly any reason for having
one-byte type or length fields in TLV definitions.  We have been burned too
many times.

This is something that should be high on the list of fixes if there is ever a
BGP-5.

Thanks.  -- Enke

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Mar 2017 15:06:59 -0400

Eric: 

<wg chair hat off> 

<individual contributor hat on> 

Thank you for the clarification.   Suggest your solution in a draft if you
believe it is complete.  I only care that operators problems are fixed. 

<individual contributor hat off> 

Cheerily, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Thursday, March 23, 2017 2:51 PM
To: Susan Hares; 'John G. Scudder'
Cc: [email-masked]
Subject: Re: [Idr] Thoughts on
https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

 

3)      On code point squatting, operators had real problems with the
current situation.   Job said "automatic checks on drafts",  Sue said "IETF
Standard + DE of BGP chairs where IETF Consensus wins"

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Mar 2017 15:09:19 -0400

Thanks for the ideas!  

1) boilerplate text for allocations, 
2) flagged issues to one WG 
3) cross-WG review button in datatracker.  

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, March 23, 2017 2:46 PM
To: Susan Hares
Cc: 'Eric C Rosen'; 'John G. Scudder'; [email-masked]
Subject: Re: [Idr] Thoughts on

On Thu, Mar 23, 2017 at 02:13:07PM -0400, Susan Hares wrote:
> - If flagging for more eye review is the case, then Job's suggestion 
> is the way forward.  It works for most YANG modules.

> - If having the expertise to review the "flag" is the issue,  1 WG 
> being in charge of the situation will suffice with the current setup.
> - if cross-review in all BGP working group is issue - then try my 
> registries proposal + IETF consensus.
> - if distrust of a single answer from WG shepherd, WG chair or set of 
> WG chairs - this draft + Eric's suggestion for who can review.

> If we can define the largest concern(s), let's we could start with 
> that solution.

-- Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Mar 2017 18:52:58 -0000

Returning to this after a while away, I wonder whether the problem doesn't have
a deeper root and so a simpler solution.

The problem could be stated as "Sometimes code points are assigned from BGP
registries through IETF consensus documents without proper care."
And the perceived solution is that the assignment should be reviewed by suitably
knowledgeable people. 
As Jeff says, "all eyes need to be pulled to one place."

I don't think this problem is unique to BGP (although obviously, those involved
on this list care most about BGP).
Where else does it come up in the IETF and how is it handled?

Some working groups are recognised as the centre of expertise for a protocol.
There is an expectation that *all* protocol extensions are done in that WG. This
is usually captured in the charter so that other WGs know where they stand.
Some working groups are recognised as the centre of expertise for a protocol.
There is an expectation that *all* protocol extensions will be reviewed by that
WG. This is usually captured in the charters of other WGs so they know they must
send documents for review.
Some protocols are acknowledged to have a base wider than one WG and a
Directorate exists to help the ADs by reviewing the documents (just like
RTG-Dir). This relies on the review being triggered.

I like Sue's 3 points and I think they would catch the majority of cases. They
don't, of course, ensure that SNAFUs won't arise. And they don't stop people
wilfully dodging. But they are very light touch, and that is to be applauded.

Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

> From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: 23 March 2017 19:09
> To: 'Jeffrey Haas'
> Cc: [email-masked]

---

From: t.petch <[email-masked]>
Date: Wed, 29 Mar 2017 10:20:34 +0100

---- Original Message -----
From: "Adrian Farrel" <[email-masked]>
Sent: Friday, March 24, 2017 7:52 PM

> Where else does it come up in the IETF and how is it handled?

A propos of which,

draft-evens-grow-bmp-adj-rib-out-00

squats on four values in 'BMP Statistics Types' and, although not
mentioned in IANA Considerations, redefines a bit  in BMP Peer flags.

The GROW WG appears not to have a procedure to deal with this.  Should
we take the authors,

 T. Evens
 S. Bayraktar
 M. Bhardwaj
 Cisco Systems
 P. Lucente
 NTT Communications

tie them to a stake in the foyer and throw rotten eggs at them?

Tom Petch

> wilfully dodging. But they are very light touch, and that is to be
applauded.
https://www.ietf.org/id/draft-hares-idr-bgp-
> > registries-01.txt

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 29 Mar 2017 09:28:10 -0500

I've already brought it up with them and I expect they'll be correcting it. No involuntary restraints or decomposing food were required. They're all new authors so presumption of good intent is indicated (not that it ever isn't, absent evidence to the contrary).

Thanks for bringing it up.

--John

On Mar 29, 2017, at 4:20 AM, t.petch <[email-masked]> wrote:
...

---

From: t.petch <[email-masked]>
Date: Wed, 29 Mar 2017 16:18:27 +0100

John

Should we be - well we should be IMO - asking IANA to make it clearer?

Go to
http://www.iana.org/protocols
and you get the impression that fill in a form and the assignment is on
its way; which in some walks of life it is.

I think we should be saying on that page that updates to registries
require the following of a procedure, varies with the registry but will
involve action by the IETF.  We don't want to put people off except when
they are squatting when we do.

The current front matter deals with creating a new registry - see RFC
5226 - but not with assigning new entries in an existing registry.

One for leibacotton I think.

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
Sent: Wednesday, March 29, 2017 3:28 PM

I've already brought it up with them and I expect they'll be correcting
it. No involuntary restraints or decomposing food were required. They're
all new authors so presumption of good intent is indicated (not that it
ever isn't, absent evidence to the contrary).

--John