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

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

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:[e-mail]] 
Sent: Thursday, March 23, 2017 1:29 PM
To: John G. Scudder
Cc: Susan Hares; Adrian Farrel; [e-mail]
Subject: Re: [Idr] Thoughts on
https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

 

On 3/22/2017 2:36 PM, John G. Scudder wrote:



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.


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.