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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 23 March 2021 19:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F973A13CC; Tue, 23 Mar 2021 12:53:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-ls-registry@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares <shares@ndzh.com>, Jie Dong <jie.dong@huawei.com>, aretana.ietf@gmail.com, jie.dong@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161652922871.32321.1505404099537514178@ietfa.amsl.com>
Date: Tue, 23 Mar 2021 12:53:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/z1SfLMhxH5ZFEXnnbcsnaGwXu5M>
Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 19:53:49 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-ls-registry-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document changes the registration policy to "Expert Review" which,
as even quoted in this document, "has no requirement for a formal
document".  Yet the specific guidance to the expert is written as if
there will always be a document: consider "[i]f the document is not
adopted by the IDR Working Group", "IANA will update [...] a reference
to the associated document", "[i]n the event that the document is", ...

Is there a requirement for a document or not?  (Alternately, what
happens if there is a request with no associated document?)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

The order the sub-registries are listed in here does not match the order
used at
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml
.

Section 2.1

   2.  The Designated Experts SHOULD only consider requests that arise
       from I-Ds that have already been accepted as Working Group
       documents or that are planned for progression as AD Sponsored
       documents in the absence of a suitably chartered Working Group.

Am I reading this correctly that the only provision for non-IETF
documents to allocate codepoints is to violate the "SHOULD" here?  (I
assume they would still go through the IDR review, etc.)

   5.  The Designated Experts MUST then review the assignment requests
       on their technical merit.  The Designated Experts MAY raise
       issues related to the allocation request for further
       consideration before the assignments are made.

Further consideration by whom, in what venue?  (When does the further
discussion terminate?)

   8.  In the event that the document is a Working Group document or is
       AD Sponsored, and that document fails to progress to publication
       as an RFC, the Working Group chairs or AD SHOULD contact IANA to
       coordinate about 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

IIRC it is rather unusual for WG chairs to interact directly with IANA
in an official role; we see DEs and ADs be named more often.  (Not that
I'm asking for more work for ADs, of course!)

Section 3

I appreciate the new security considerations :)