Subject: Re: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06

From: Alvaro Retana <[email-masked]>
Date: Wed, 15 Apr 2020 07:22:08 -0700

Ping!

On February 11, 2020 at 11:31:30 AM, Alvaro Retana ([email-masked])
wrote:

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

---

From: John Scudder <[email-masked]>
Date: Wed, 15 Apr 2020 18:36:19 +0000

Hi Alvaro,

Thanks for the review! I’ve uploaded -07 to address your comments. Some replies in line below. 

WG: Please take note this adds three more deprecated code points, for “Cisco multi-session”, “cumulus hostname” and “Operational message”, see the bottom of this message.

—John

> On Feb 11, 2020, at 11:31 AM, Alvaro Retana <[email-masked]> wrote:
> 
> John:
> 
> 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.
> 
> 13       This document updates RFC 5492 by making a change to the registration
> 15       formerly designated "Reserved for Private Use" is divided into three

Done.

> 66       "Reserved for Private Use".  Subsequent experience has shown this to
> 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
> [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.

Done.

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

Done.

> [nit] The invitation is not needed, since the draft is now “done” and
> the values are already included...

Done.

> 119       Registry Owner/Change Controller: IESG

I take it this is a request to remove the explicit listing of IESG as change controller, because it’s the default? OK, done.

> 121       Registration procedures:

Done.

> 131       Note: a separate "owner" column is not provided because the owner of
> [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".

I’m a little confused by this but it’s no skin off me either way; done.

> 134       IANA is requested to perform the following new allocations within the
> 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].
> 

OK, thanks. I think these were all raised by Thomas Mangin (thanks, Thomas). Here’s how I think they are to be handled:

131: Relocated to 68 now (the standardized code point). Deprecated.
184: Relocated to 73 (the assigned code point). Deprecated.
185: This is a little more thorny. The draft in question is draft-ietf-idr-operational-message-00. It’s a WG draft, but a dead one (I think I’ll kick its state to “dead” after I’ve sent this; it hasn’t been updated in 8 years). There is no assigned code point, nor is there likely to be. In normal course of affairs if things had gone differently, maybe we would have early-allocated a code point. Then, based on the document not progressing, the code point would have been reclaimed by IANA and listed as deprecated. So, I’m going to also list this one as deprecated even though there’s no standardized/assigned code point for it.

If anyone has objection to any of these additions, please make some noise now. 

> [1] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/eIoTAz3wS6dJMKBoIxwrAk98lxM__;!!NEt6yMaO-gk!SRlG_yjBkTNVEvO96n5W07LcEnafwsyyQ6ssqmTyYo_dTNtUESJCIxbBiC5RSw$

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 15 Apr 2020 12:12:13 -0700

Thanks John!

I’ve started the IETF LC.

If anyone in the WG has comments about the additional code points, please
make them during the IETF LC period (to end on Apr/30).

Thanks!

Alvaro.

On April 15, 2020 at 2:36:22 PM, John Scudder ([email-masked]) wrote:

Thanks for the review! I’ve uploaded -07 to address your comments. Some
replies in line below.

WG: Please take note this adds three more deprecated code points, for
“Cisco multi-session”, “cumulus hostname” and “Operational message”, see
the bottom of this message.