[Idr] [IANA #1435575] Early review: draft-ietf-idr-rfc4360-bis-01 (IETF 124)

[Amanda Baber via RT <[e-mail]>]

Dear Authors (cc: idr WG),

Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about this document:

https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc4360-bis-01

1) The BGP Transitive Extended Community Types registry currently has these registration procedures:

Range Registration Procedures Note
0x00-0x3f First Come First Served
0x80-0x82 First Come First Served see [RFC9184]
0x83-0x8f Reserved for Experimental Use see [RFC3692]

This document consolidates the last two:

0x80-0x8F First Come First Served or Experimental Use (see [RFC3692] and [RFC9184])

This is problematic. If these registration procedures aren't separated, we could end up assigning values that people were using for experimental purposes. Can Experimental Use continue to have its own separate range?

2) RFC 4360 is a reference for “EXTENDED COMMUNITIES” in the BGP Path Attributes registry at https://www.iana.org/assignments/bgp-parameters. Because this document is obsoleting that one, it needs to tell us whether to replace that reference. (References are typically replaced.)

Alternatively, if it’s correct that both that reference and the other references to RFC 4360 at https://www.iana.org/assignments/bgp-extended-communities should be replaced, the section could simply state up front that all references to RFC 4360 in the IANA registries will be replaced with references to this document.

3) Other issues stem from the fact that this document states that IANA will make assignments or create registries that were actually made by RFC 7153, not RFC 4360. Because the document doesn’t mention that it’s obsoleting RFC 7153, it’s not clear whether this document should replace those references to RFC 7153 or be listed as an additional reference.

While it might make sense to state that the document is defining those assignments/registries, it shouldn’t imply that they haven’t been created yet.

The issues begin with the description above Table 2.The document says that it assigns 0x00, 0x01, and 0x03 in the BGP Transitive Extended Community Types registry and 0x40, 0x41, and 0x43 in the BGP Non-Transitive Extended Community Types registry, but those assignments currently refer to RFC 7153 rather than RFC 4360. To address this, instead of stating that it’s assigning the values, the document should describe its status as a reference for those assignments. 

Specifically, it should state that it should replace RFC 7153 as the reference or be listed as an additional reference (as you prefer) for those assignments. (If it’s going to obsolete 7153 – the document doesn’t currently say that it’s obsoleting or updated 7153 – it should replace the references.)

4) There might be an issue related to this paragraph, which is carried over from RFC 4360: “The value allocated for a Regular Type MUST NOT be reused as the value of the high-order octet when allocating an Extended Type. The value of the high-order octet allocated for an Extended Type MUST NOT be reused when allocating a Regular Type.”

The potential problem is that values can be assigned via the First Come First Served registration procedure, but those values don’t receive any kind of review by anyone outside of IANA, and IANA’s Operations team isn’t equipped to make this determination. Should the First Come First Served procedure be changed to a lightweight Expert Review, with guidance to the expert that they only need to check for this? Or do the ranges of values made available in the registries' "Registration Procedure" fields already guarantee that this won’t happen?

5) The IPFIX registries include multiple references to RFC 4360:

https://www.iana.org/assignments/ipfix

If it's correct to replace those references, please add a sentence like "IANA will replace all references to RFC 4360 in the IP Flow Information Export (IPFIX) Entities registry group at https://www.iana.org/assignments/ipfix with references to this document."

If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at [e-mail].

For more information about IANA Considerations section requirements, please see

https://www.iana.org/help/protocol-registration

Best regards,

Amanda Baber
IANA