Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian Farrel <> Wed, 09 December 2020 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B6AF3A0FC6; Wed, 9 Dec 2020 01:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jEcoIeakmHRp; Wed, 9 Dec 2020 01:37:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA1C03A003E; Wed, 9 Dec 2020 01:37:02 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 0B99au7R025086; Wed, 9 Dec 2020 09:36:56 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 7A6EA2203B; Wed, 9 Dec 2020 09:36:56 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 63BF322040; Wed, 9 Dec 2020 09:36:56 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 0B99atLr017035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Dec 2020 09:36:55 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Les Ginsberg \(ginsberg\)'" <>, "'IDR List'" <>
Cc: <>
References: <0e3501d6cda2$fbf19d40$f3d4d7c0$> <>
In-Reply-To: <>
Date: Wed, 9 Dec 2020 09:36:55 -0000
Organization: Old Dog Consulting
Message-ID: <0f0901d6ce0e$d5a08860$80e19920$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGajGRKThIcpkdudESaynUGnDXA0QKP/frLqlJ/81A=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.486-10.0-31-10
X-imss-scan-details: No--13.486-10.0-31-10
X-TMASE-Result: 10--13.485700-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/xIbpQ8BhdbPVY7U3NX8JgQWEGv3gaUmenRvssirgAK22r DqsRwTo3GYSIXjbznIWRAIHPAJXHw+7Gghg9I/XgJNzc11O35nrLRD51bz5RZAg+646V68DKl5G 53p8Gu3Uzl4kBoX7TjaZCKoGDSGlIgZLBlLp+A4JVXhlmZsTdjEYj0zDHPzJpmawSaFZ/FjTa4T Y/P1WtiOivobn0qGa6caD5tpNljKpk4Y8xHTOJXDfEJhkPJ1IaQ37rdi3NWIeuiyJNZGE/iaLml xP63kmZYwLjCZ3dnYuzKHTIp86ppNgW4k6aveo4XK5keCa+bmiTnpV+S7Y80VrXKFPCbXO540tA by8Beua+k3sxQK0Oobcm8EfQO7P0RXNf1eTQ0psW8Al79bnAD6m9/6ObPjnDI0YrtQLsSUxsPA5 XUNufmZpoFjCUvmU+uo+/Nvg0IKGbLlpwRDsb9pVRzPxemJL082SgwNf6SK4ZSz1vvG+0mpKyNY XHhu5Ict0DjTY8/MMISwBeabEirS/aTczbsnfWSUAFemq7B2UX2zxRNhh61UYza41dGqxS5yGXP u0T9VkGuug1ozpSjgJvkdLM4tjFYKZZxkxcUv/0VCHd+VQiHqGnvnr+szpSh7/KLUHlCELOdxNv GpBRgl9/wEwrfAO6OzL9BDvV9GftVVrof6/yv1xWWs3RUcVrMfFOYpCI/uJEm2z04jGoE5Ioa0E zv+rNPSv7S7RSsx+ItjUr9orD06VIsznpoCaYtKV49RpAH3vk9iy1YAofaokfOKJT5um9Jxq9WS CvMRCXPD4HvxE58HtBxdKLkQVY8sR6JoiDvHCeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47hTZDOrz lZ+cHQdJ7XfU86e4kYXbobxJbKl/MtrTwS4UFODrn99kJLBJp5X2uPrshKWSgI97gGtVk/wc8MX 1KttgnnGNRRa0Uk=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2020 09:37:06 -0000

OK, thanks Les.

Best to start with "why aren't these early allocations?" 

Early allocation is a process to get around Standards Action, IETF Review,
and RFC Required by setting rules under which code points from those types
of registry can be allocated in advance of the completion of the RFC
process. 7120 includes that IANA timestamps the allocations, and that early
allocations expire automatically. They also require that I-Ds are
sufficiently stable that the meanings of code points will not change before
the RFC is published.

My understanding of the wishes of the IDR WG is that they consider early
allocation to be too restrictive. Firstly, it comes too late in the process
(IOW the stability of the draft normally requires that a code point cannot
be allocated until close to WG last call). Secondly, the process involves
the chairs and AD signing off along with the DEs, and so is too heavy and
laborious (aka slow). And additionally, early allocation requires that
attention is paid to renewing the allocations every year until the RFC is

The change, therefore, was to make the registries Expert Review precisely to
not use 7120.

I agree "similar" is a Bad Word (TM). It was my intention only to indicate
that the use of deprecation was similar to deprecation in 7120, but in this
case, more words would be better. So...

OLD (-02)
   8.  In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated following similar principles to Section 3.3 of
   8.  In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated.  A deprecated code point is not marked as allocated
       for use and is not available for allocation in a future document.
       The WG chairs may inform IANA that a deprecated code point can be
       completely de-allocated (i.e., made available for new
       allocations) at any time after it has been deprecated if there is
       a shortage of unallocated code points in the registry.


-----Original Message-----
From: Les Ginsberg (ginsberg) <> 
Sent: 09 December 2020 01:12
To:; 'IDR List' <>
Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian -

Thanx - as always - for your diligence.
I think this revision is consistent with the outcome of the email

I am concerned about Section 2.1 #8:

"In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated following similar principles to Section 3.3 of

I think the phrase "similar principles" leaves the door open to lots of
ambiguity. If you do not want to follow RFC 7120 Section 3.3, what do you
want to do? How much deviation from RFC 7120 Section 3.3 before "similar"
does not apply? I do not think leaving this a bit vague is desirable.

I am also not clear on why you say (below) that we are not doing early
allocations. If these aren't early allocations, what are they? Which also
makes me wonder why you could not simply say "follow RFC 7120 Section 3.3"??


> -----Original Message-----
> From: Idr <> On Behalf Of Adrian Farrel
> Sent: Tuesday, December 08, 2020 12:45 PM
> To: 'IDR List' <>
> Cc:
> Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> Hi,
> Thanks to all for the useful input and sorry for the long delay while
> "things" got in the way.
> I made some changes to the draft according to Alvaro's comments and then
> updated the DE guidance per the discussions on list.
> Ketan noted that point 6 of the guidance in RFC 7370 talks about
> per RFC 7120. That only applies to early allocations, and that's not what
> we're doing. I think it is still worth carrying text about what happens if
> the document never becomes an RFC, so I have retained something similar,
> but
> different. I hope this is consistent with what Les said.
> Acee additionally suggested that code point requests should be "fully
> transparent to the LSR list". I haven't added this, but it would be simple
> to do if there is support for it.
> Since the text changes are pretty much the whole draft, the easiest thing
> seems to be to post an update and then invite you to review and comment.
> So
> that's what I have done.
> Cheers,
> Adrian
> _______________________________________________
> Idr mailing list