[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 :)
- [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-… Benjamin Kaduk via Datatracker
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Adrian Farrel
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Adrian Farrel
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk