Re: [Idr] draft-cli-bgp-ext-com-registry-update: WG adoption and IPR Call and WG adoption (6/24 to 7/8)

[John Scudder <[e-mail]>]

(As an individual contributor)

I’ve just read through the draft. As advertised it is short, sweet, and to the point. I support its adoption, and thank Christoph for writing it.

I will note that it would be possible to carve out just the three mis-assigned code points without changing the registration procedures for the entire registry, i.e. we could leave the Experimental ranges as experimental, save for those three code points. However, as most of you know I’m not a big fan of Experimental for BGP protocol allocations, it doesn’t seem to be worth much, so I’m just as happy to see the change made. In any case, the WG should adopt the draft either way, since no matter what, the three code points in question should be clarified.

I do want to raise one potential concern about the reclassification of the ranges: since Experimental is completely ungoverned (see https://tools.ietf.org/html/rfc8126#section-4.2), there could in theory be implementations in the field already using code points from this space. I think it’s not very likely that there ARE such, but there could be. (If someone knows of an example of one, they should say so right now of course.)

Thanks,

—John

On Jun 24, 2020, at 9:21 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:



This begins a 2 week WG adoption call for:
draft-cl-idr-bgp-ext-com-registry-01.txt

You can download the draft at:
https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJrPzpyVA$>

This document updates several BGP Extended Community registries in
   order to replace the "Experimental Use" registration procedure in
   some entries, since their use is clearly not experimental and thus
   misleading.

This draft should be consider as part of the group of drafts that are trying to clarify and speed up the registry process.

Christoph  you should send an IPR statement regarding this draft to the IDR WG.   Since you normally prompt with your email, I am running the IPR call and WG Adoption call in parallel.

The other drafts which are in process for registry clean-up are:

1) draft-ietf-idr-capabilities-registry-change-09<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJS6xrsfg$>
      John Scudder: in RFC editor’s queue
2) https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLfv03utQ$>
     Adrian Farrell: In Shepherd’s queue, top of list.

These two drafts provide clean-up to the IDR capabilities and the BGP LS registry process.    This draft provides a set-up clean-up instructions for the Extended Communities registries.

Please consider if this clean-up will lessen confusion and help us streamline the process.  If you have other ideas for cleaning up the BGP registries, you are welcome to include the information on this thread.

Thank you, Sue

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLWNNmtxw$