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

Adrian Farrel <> Wed, 24 March 2021 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4A943A340D; Wed, 24 Mar 2021 12:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0EZhqx-elmz3; Wed, 24 Mar 2021 12:39:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D23B3A33F5; Wed, 24 Mar 2021 12:39:17 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12OJd2KE021655; Wed, 24 Mar 2021 19:39:02 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 3111D2203D; Wed, 24 Mar 2021 19:39:02 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 1BB112203B; Wed, 24 Mar 2021 19:39:02 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12OJd0Db028482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Mar 2021 19:39:01 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Lars Eggert'" <>, "'The IESG'" <>
Cc: <>, <>, <>, "'Susan Hares'" <>, "'Jie Dong'" <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 24 Mar 2021 19:39:00 -0000
Organization: Old Dog Consulting
Message-ID: <0dea01d720e5$57d670f0$078352d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHIl4swlFyxdRFcHjpjLXjh/JqINKqwlsMw
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--0.334-10.0-31-10
X-imss-scan-details: No--0.334-10.0-31-10
X-TMASE-Result: 10--0.334000-10.000000
X-TMASE-MatchedRID: xcONGPdDH5rxIbpQ8BhdbPHkpkyUphL9+IfriO3cV8RGM2uNXRqsUsqa e4dFK5zKsf3OfUZ1vbKo6HqtluTApapEIvDEr24EZdorcofH/Gkog3IF7wM1sjhdESD0qLXT9Vl GBjCDnciqECl25tRXR06puutjQMDQPKhafG4AD+zece0aRiX9WuDTYjejIZTwRqYP52QLif3/ut aJEclLYV890HgjV6tn5r+L0dHMjR9QsilTGCZzpL5aJkcG4ya+PXu1L28jSnGpK4gpaghAL+mnv oERiCEKwXtozz/dHrGeYbAkeZdTXqyfNA15+sctEWc+zY28CNL2X2nyY2WSCe/AZTBTiDOZIwg3 Vd+9mjAPAwHSVrCOFneyY0zYuIsrGF084UG8/2TUF7aqwb35brzETYfYS4xZ3uv+42JvdpX65H5 /xydEb4ybcFX8VmEtB+I75w7Uv8q/WXZS/HqJ2lOm2gN+nomsxEHRux+uk8ifEzJ5hPndGfuaa3 IzNCV03Jw1Pr9sCasZy7wZe7RswmdRVhKIWFyJoOoA+SAHoARrcmUzfJZRrmzD9xLxbK5ujQ0Zv Pu8xRzniHGEx0su9sQqHltHU9gWh/yQr4rUA+khyumgjE26daI8pDPbYZMRVlxr1FJij9s=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
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: Wed, 24 Mar 2021 19:39:21 -0000

Hi Lars,

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

> 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 sufficient?

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
   - a non-WG I-D doesn't qualify
   - a non-IETF document doesn't qualify
- 7120 allocations have to be renewed
   - this is extra effort 
   - only one renewal is allowed unless the IESG is invoked "under rare circumstances"
   - the code point "expires" if someone forgets to renew