Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Susan Hares <> Thu, 25 March 2021 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 944FA3A23A6; Thu, 25 Mar 2021 07:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IvQBF4Kri_8Q; Thu, 25 Mar 2021 07:15:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 167263A23A4; Thu, 25 Mar 2021 07:15:53 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Ketan Talaulikar \(ketant\)'" <>, "'Lars Eggert'" <>, "'The IESG'" <>
Cc: <>, <>, <>, <>
References: <> <0dea01d720e5$57d670f0$078352d0$> <> <>
In-Reply-To: <>
Date: Thu, 25 Mar 2021 10:15:37 -0400
Message-ID: <00d901d72181$54bdc660$fe395320$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHIl4swlFyxdRFcHjpjLXjh/JqINAIuu7BNAezF3c0Cx/f8Xap6tfAw
Content-Language: en-us
X-Antivirus: AVG (VPS 210324-0, 03/24/2021), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
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: Thu, 25 Mar 2021 14:15:59 -0000

Ketan and IESG:

<WG chair hat on> 
Ketan has correctly summarized the WG discussion.  The WG goal is to enable
the 2 implementations to occur prior to standardization, and to allow the
implementations to keep those values. 

If other WGs have not seen this problem, perhaps it is because they do not
require 2 implementation before standardization.  We are adding this
additional registry work to make this process easier for the implementers. 
<WG chair hat off>

[personal opinion] 
If the process occasion creates a conflict, I believe it is worth the risk.
It is critical to get early implementations of protocols with stable values.
Running code and rough consensus is a slogan I truly believe in.  


-----Original Message-----
From: Ketan Talaulikar (ketant) [] 
Sent: Thursday, March 25, 2021 7:54 AM
To: Lars Eggert; The IESG
Cc:;;; Susan Hares;
Subject: RE: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)


I believe Adrian has made all these points already in his responses on these
threads, and so perhaps this is just an effort at summarizing them for the
IESG Discussion. 

(Request the WG Chairs to correct if they see this different from the WG
consensus view).

1) The "Specification Required" policy is currently in place for this
registry per RFC7752. The WG was informed that Internet-Drafts (even WG
drafts) do not meet the criteria of "permanent and readily available" thanks
to the boiler-plate text (below) that exists in Internet-Drafts. i.e. WG
could not get IANA allocations based on WG drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

2) As a result of (1), the WG has had to follow the early allocation
procedures of RFC7120 for a large set of allocations and documents (BGP-LS
is a bit busy!). IDR requires 2 implementations to publish drafts as RFCs.
Things take time. The WG, chairs, AD and in some cases the IESG have to do a
lot of process work to retain the allocations when there are delays in
getting to publication.

3) The WG was looking for IANA allocation based on WG documents. With the
guidance of WG chairs, our AD and participants with more experience in IANA
allocations, we (the WG) took a step back to "Expert Review" so as to avoid
the early allocation process overheads. Please note that we have sufficient
code-point space.

4) The guidance to DE was only improved/enhanced but that, IMHO, is more
secondary in nature and something that happened over the course of review of
the document to improve it.

Finally, thanks again to Adrian for coming up with the solution (i.e. the
draft) and taking it through the process for the WG!


-----Original Message-----
From: Idr <> On Behalf Of Lars Eggert
Sent: 25 March 2021 02:26
Cc:;; The IESG <>rg>;; Susan Hares <>
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)


On 2021-3-24, at 21:39, Adrian Farrel <> wrote:
>> I'm putting in a "discuss" DISCUSS that I expect to clear during the 
>> call. Several other ADs raised issues that deserve discussion. While 
>> they may not fall under the "discuss criteria", they also don't fall 
>> under the "discuss non-criteria" and I want to make sure we spent some
time on discussing them.
> That's perfectly reasonable.
> I wish there was a way for the IESG to table something for discussion
without using the "Discuss a document" hook which makes the authors (and the
watchers) feel that *they* should be part of the discussion. But, anyway, it
seems that there is something here that the IESG needs to discuss, so
"whatever works."

I wish so, too, but we're limited by the current toolchain here, as you
know. I guess I could have put an explicit "non-ADs ignore this" into the
text above...

>> Section 2.1, paragraph 4, comment:
>>>   In all cases of review by the Designated Expert (DE) described here,
>>>   the DE is expected to check the clarity of purpose and use of the
>>>   requested code points.  The following points apply to the registries
>>>   discussed in this document:
>> The process outlined in the rest of this section seems to define 
>> rules that are basically equivalent to doing an RFC7120 "early 
>> allocation" for these registries. Why is that existing process not
> It achieves a similar end with some slight variations. I can't speak for
the WG as to why they preferred this approach, but:
> - 7120 requires a stable WG I-D. Thus:
>   - an early WG I-D doesn't qualify

RFC7120 requires:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

It seems one would want this sort of stability here, too?

>   - a non-WG I-D doesn't qualify

It's not clear to me that RFC7120 requires this. Also, this document says
"SHOULD only consider requests that arise from I-Ds that have already been
accepted as Working Group documents..." which is a similar limitation.

>   - a non-IETF document doesn't qualify

RFC7120 also applies to "Specification Required" registries for which no
IETF document is needed.

> - 7120 allocations have to be renewed
>   - this is extra effort
>   - only one renewal is allowed unless the IESG is invoked "under rare
>   - the code point "expires" if someone forgets to renew

Fair point. But this document defines a mechanism whereby chairs and the ADs
are tasked to remember to make IANA deprecate the codepoints when a document
isn't published (or I guess published with incompatible changes to the
revision for which the allocation was made). That seems to suffer from
similar drawbacks.