[Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06
Alvaro Retana <aretana.ietf@gmail.com> Tue, 11 February 2020 16:31 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667B12023E; Tue, 11 Feb 2020 08:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQucAr4HZBwg; Tue, 11 Feb 2020 08:31:56 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6894F120122; Tue, 11 Feb 2020 08:31:33 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id r21so5415738edq.0; Tue, 11 Feb 2020 08:31:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=EU3ooiCe0ZSjhgRUi+pdoIsHG4Nl0bU+VntU5rTzAKs=; b=Db8v8gaQpm9CdwdyO3AKANy7XxpN4gw5m3WuriAWgwnPfjE5my1d6/qn5DTz7OvUdx rB3OQ+Ytw19VMYAafxWNZQD8l7Qhi3ca+Vq9uwX0U/IlCNnIsAWfKZUqtIZFqKobNArw g4ipA3BMFIo7xjuBRPbnS3s8uw9afxULeDXqUESpTtXaCEymbjioPvHQesZuADq+7zXh LD1rFCE6fvDEo3euWCEwSRxulEs0CxgOy8I3JCWqhQIrS7H8kN5GkU8cKwV4QN/pAVxc Y+qMzKAqPBTzoD0BzcVOTTbAV/Vb4KQRMRiQvyUgchMhGmCIMmb48dLkxyZ3dt+Qd3uC rIRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=EU3ooiCe0ZSjhgRUi+pdoIsHG4Nl0bU+VntU5rTzAKs=; b=SHBDovp3qZuo+u0dU8n/gmu0LUbvovKP1A2wq7FHlMXQW0S3lqhcxv4NiUEo0rcGsz 9FaC2V8pvcip3R/FCJh/D3xCpHB4n7HnCfiElB3qokuuXs3tQGcYhM3RJSU3ZMlwNAtl vFiDKIgvBKrT0vZ/JOybUScx97OZM7dqzbNsC3e9+5wmCKLMXi5Ezn0hGRrMyZ2dDqCU z4jNw1XpJVIk0qbIkkz4q9Ev16cFHkOpzuOCMzWW8I4n8z1Ojvy9livm3NcBqoDEc5KH 6bTXShjmkWNhjGE/bO9ptdWHaeh5zTUKL1O4Sy83d0utnxqiyw0e3FPH5fkqLnsLWpeL jpRg==
X-Gm-Message-State: APjAAAVi/eEYkawbSAiILT3kYA9PBjMNjpF8vaqQc7HOo0gt/zTWesKn baFDruXNJ9e23MxxfHWVJhVYIEoiW4eqh3UO6Lv8NQ==
X-Google-Smtp-Source: APXvYqzWWIHIvkMe4yy8rrrAf7HZ6y6L3UQwq7oGKy5YqZvydCwNoNGIcnr+HP3kxCvHllB+WAmCTMaJP4omF6l0qcU=
X-Received: by 2002:a17:906:9458:: with SMTP id z24mr6950812ejx.155.1581438691526; Tue, 11 Feb 2020 08:31:31 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2020 16:31:30 +0000
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Tue, 11 Feb 2020 16:31:30 +0000
Message-ID: <CAMMESsz1AFH8mAVHCBJg6gSAydfFP0aWmox5AzgQkPYKrmaN4Q@mail.gmail.com>
To: draft-ietf-idr-capabilities-registry-change@ietf.org
Cc: Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, "idr@ietf. org" <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OFQOEM3lBjZbhUtGhh5QUH5DJC4>
Subject: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 11 Feb 2020 16:31:59 -0000
John: Hi! Thanks for your work on this document! I have a couple of important items that need to be addressed before moving this document forward, specifically about change control and a couple more values that should be deprecated. Please see in-line. I will wait for an update before starting the IETF LC. Thanks!! Alvaro. [Line numbers from idnits.] ... 11 Abstract 13 This document updates RFC 5492 by making a change to the registration 14 procedures for BGP Capability Codes. Specifically, the range 15 formerly designated "Reserved for Private Use" is divided into three 16 new ranges, respectively designated as "First Come First Served", 17 "Experimental" and "Reserved". [nit] s/Experimental/Experimental Use ... 63 1. Introduction 65 [RFC5492] designates the range of Capability Codes 128-255 as 66 "Reserved for Private Use". Subsequent experience has shown this to 67 be not only useless, but actively confusing to implementors. BGP 68 Capability Codes do not meet the criteria for "Private Use" described 69 in [RFC8126] section 4.1. An example of a legitimate "private use" 70 code point might be a BGP community [RFC1997] value assigned for use 71 within a given Autonomous System, but no analogous use of 72 Capabilities exists. [nit/potential rathole] I don’t see why Capabilities Advertisement can’t meet the “for private or local use only” criteria in rfc8126. I guess we just don’t know of any local-only capability! ;-) Seriously, I’m not going to object the justification, or strongly ask you to change it, but others in the IESG might. Suggestion: Leave just the first two sentences. ... 85 2. Discussion ... 100 The reason for designating "IESG" as the change controller for all 101 registrations is that while it should be easy to obtain a Capability 102 Code, once registered it's not a trivial matter to safely and 103 interoperably change the use of that code, and thus working group 104 consensus should be sought before changes are made to existing 105 registrations. [minor] I don’t think this paragraph is needed because “For registries created by RFCs in the IETF stream, change control for the registry lies by default with the IETF, via the IESG.” [rfc8126] [] I think it is confusing (at least to me) the text about “working group consensus” if the change controller is the IESG, and we're dealing with FCFS. Again, I don’t think this paragraph is needed. 107 Finally, we invite implementors who have used values in the range 108 128-255 to contribute to this draft, so that the values can be 109 included in the registry. Values that have been reported, are 110 included. [nit] The invitation is not needed, since the draft is now “done” and the values are already included... 112 3. IANA Considerations ... 119 Registry Owner/Change Controller: IESG [] See above. 121 Registration procedures: 123 +---------+-------------------------+ 124 | Range | Registration Procedures | 125 +---------+-------------------------+ 126 | 1-63 | IETF Review | 127 | 64-238 | First Come First Served | 128 | 239-254 | Experimental | 129 +---------+-------------------------+ [minor] Please add Figure/Table numbers. 131 Note: a separate "owner" column is not provided because the owner of 132 all registrations, once made, is "IESG". [major] The IANA review (which I now notice was only sent to Sue and me), says: "Since part of the registry will be First Come First Served, we'll be adding a change controller column, per RFC 8126." [That is the full review...] "Change controller" and "owner" are the same thing; I think it would be ok to rename the "Reference" column (below) to "Reference / Change Controller". 134 IANA is requested to perform the following new allocations within the 135 "Capability Codes" registry: 137 +-------+-----------------------------------------------+-----------+ 138 | Value | Description | Reference | 139 +-------+-----------------------------------------------+-----------+ 140 | 128 | Prestandard Route Refresh (deprecated) | (this | 141 | | | document) | 142 +-------+-----------------------------------------------+-----------+ 143 | 129 | Prestandard Outbound Route Filtering | (this | 144 | | (deprecated), prestandard draft-li-idr- | document) | 145 | | flowspec-rpd-04 (deprecated) | | 146 +-------+-----------------------------------------------+-----------+ 147 | 130 | Prestandard Outbound Route Filtering | (this | 148 | | (deprecated) | document) | 149 +-------+-----------------------------------------------+-----------+ 150 | 255 | Reserved | (this | 151 | | | document) | 152 +-------+-----------------------------------------------+-----------+ [major] There is mention in the mail archive of other values that should also be deprecated [1]. - "131 (CISCO multi-session)" - "184, cumulus hostname draft" - "185, operational draft" [1] https://mailarchive.ietf.org/arch/msg/idr/eIoTAz3wS6dJMKBoIxwrAk98lxM
- [Idr] AD Review of draft-ietf-idr-capabilities-re… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-capabilitie… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-capabilitie… John Scudder
- Re: [Idr] AD Review of draft-ietf-idr-capabilitie… Alvaro Retana