Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)

Adrian Farrel <> Mon, 22 March 2021 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 513AF3A1183; Mon, 22 Mar 2021 04:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 JLNqqlOeRRHB; Mon, 22 Mar 2021 04:17:03 -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 548403A11B5; Mon, 22 Mar 2021 04:17:03 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12MBGjhE010995; Mon, 22 Mar 2021 11:16:46 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 29AD822040; Mon, 22 Mar 2021 11:16:46 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 13E072203C; Mon, 22 Mar 2021 11:16:46 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12MBGiL8011542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Mar 2021 11:16:44 GMT
From: Adrian Farrel <>
To: 'Robert Wilton' <>, 'The IESG' <>
Cc:,,, 'Susan Hares' <>, 'Jie Dong' <>,
References: <>
In-Reply-To: <>
Date: Mon, 22 Mar 2021 11:16:43 -0000
Organization: Old Dog Consulting
Message-ID: <09f501d71f0c$d895e610$89c1b230$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQISpCtOTGl/ogogJKNQG5/oPIb4uKoYymjA
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--6.621-10.0-31-10
X-imss-scan-details: No--6.621-10.0-31-10
X-TMASE-Result: 10--6.621100-10.000000
X-TMASE-MatchedRID: I31hiQfYWUPxIbpQ8BhdbBriZI4JYHjfCDS1v5wuIQv6fbviu9h5w4u3 renu5Y0wHODVKmi6N/vg3RXnkHWN45ig59GoGvpV9FHjNotpdxCI895gG3J6zV4gIatY6WE1g7p bZl2hQA6eR1lkyTPKbSLuZAk1qAxOcndo43FM21SOmGwogjI1ifiH64jt3FfESX8n1Gj4wAGmxb BE1xfvbp1ZJ+rxmk0AbRtVxthAhwKWPDaj6G1/i0lABXpquwdlQWEGv3gaUmcrxUs8Nw/2fn/WD u2EM8cZ6WEQTaKEXuQYMPaM+DRRbJoeVV4b43HMEG8bcwjf6u5ezmeoa8MJ83m3tbX0ek5IBdkt VeUMQ93XR4p4P9orT4Zd4VGtMS/BHSbo90eeu4KhNqy1ydmnqZTb3PKAwoR/SbvbKPrzpde5xCJ UCVj6GjnpSV66h8LNVOX24pMt3gOcnJlsy1/XIbqImyaR0axZc1tWSEjKtCNpsnGGIgWMmWPxfN 2peGdew29mCuIgJUfJuBEl6eziHdBUMX40Rzs4OGTV4fFD6yBqtMy+e+oG4g7dkv5f5dVd8z70X DTUjsbgQGH3/X1T48+8uGzhb+lvwLWaq3OxDLYK4MBRf7I7pibiV/S36CI44ZmC0TPZtogFazh1 tJIpXPDJqLS+OyfGncfvvbgs0qVAk+eOxCIOn8n9tWHiLD2GoIA9EE5IY7RNKfEBXpaqAonzgHW N7u0mBix2LEbt873kVNl3MoaH1FelcRfGGYzXAjoaSw0EjFV9LQinZ4QefBrZLyuS+0VxsOzOnc rmCoOOhzOa6g8KrfJp/ZnRJUZtHkqA8kb23JsnIBc1QxMlWDJABTOebJX1GdpXv7q0eHtDDKa3G 4nrLQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with 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: Mon, 22 Mar 2021 11:17:09 -0000

Hi Rob,

Thanks for chatting.

> My first observation on this document is that it does not really explain why
> this change is being made.  I think that it would be helpful  for readers if
> the introduction briefly explained why the allocation policy is being changed.

Answer is similar to that I gave Martin: we don't normally explain how we chose IANA policies in our documents, although there is often heated and confused debate about which policies to apply and how large ranges should be.

In this specific case, as pen-holder, I'm not sure I can put my finger on exactly why the WG felt it important to change, only that this is the result they wanted to end up with.


> However, I have the same concern that Martin raised, i.e., this uses an IANA
> "Expert Review" classification where the instructions to follow are broadly
> "IETF Review" or "Standards Action", and I don't understand why one of those
> classifications isn't being used instead.

Both "IETF Review" and "Standards Action" generally require completion of the RFC process before allocation can be made. This is annoying for implementers in registries where new codepoints are being assigned thick and fast. It encourages squatting and conflicts.
The "Early Allocation" procedures allow this to be salvaged, but those procedures come at a cost that the WG thought was too much:
- the document making the assignment must be a WG document
- the WG document must be "stable"
- early allocations must be renewed yearly with the intent of a 2-year maximum
OTOH, "Expert Review" allows assignment to be made once only, and also for "less mature" documents.


> Section 4.11 of RFC8216 explains that the use of well-known policies aids
> community experience and wide understanding, and that the policies are in
> increasing order of strictness.  But the use of "Expert Review" does not match
> what I would naturally expect that IANA policy to mean.

I think it is not commonly understood that for "Expert Review", "The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry" [RFC8126]. Very many legacy registries don't have proper guidance for the DEs, but it is a fundamental part of the concept of "Expert Review" and this can be gauged by the size of Section 5 of RFC 8216 (10% of the whole document).

In terms of increasing order of strictness, do you think that this document has elevated "Expert Review" above the next category which is "Specification Required"? There is a debate to be had here about whether "Specification Required" includes the use of an Internet-Draft when it says "permanent and readily available public specification". This seems to me to be a Big Debate (TM) that the IESG might want to lead the IETF community through, but perhaps one that we don't want to use to gate the progression of this document. FWIW the arguments seem to centre around:
- can an expired I-D be found in a permanent and definitive repository?
- does the registry include the revision number for an I-D?
- the I-D contains boilerplate explicitly stating that it is inappropriate to reference it
- 8126 suggests that an RFC is an ideal means of meeting the requirement

But apart from that, 8126 says that "Specification Required" is the same as "Expert Review" with the addition of the requirement for a publicly available and stable spec.

I don't think that this document brings "Expert Review" close to the next in line which is "RFC Required".

So, all these words written and in brief, is there any action we should take for this document?