Thanks for catching the error, Tom. I’ve uploaded version 04 to correct it.
—John > On Sep 21, 2023, at 12:28 PM, tom petch <[email protected]> wrote: > > I cannot make sense of this. > > The I-D updates the registries defined in RFC7854 saying > ==================== > * BMP Peer Down Reason Codes > ... > For each of these registries, the ranges 32768-65530 whose > registration procedures were "Specification Required" are revised to > have the registration procedures "First Come First Served". > ============== > The I-D does not specify the section numbers in RFC7854 but it would appear > that Peer Down Reason Codes are 10.8 according to the table of contents > 10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 24 > > Erratum 7194 says > 3 > > Section 10.8 says: > > Information type values 0 through 32767 MUST be assigned using the > "Standards Action" policy, and values 32768 through 65530 using the > "Specification Required" policy, defined in [RFC5226]. Values 65531 > through 65534 are Experimental, and values 0 and 65535 are Reserved. > > It should say: > > Information type values 0 through 127 MUST be assigned using the > "Standards Action" policy, and values 128 through 250 using the > "Specification Required" policy, defined in [RFC5226]. Values 251 > through 254 are Experimental, and values 0 and 255 are Reserved. > > Notes: > > In Section 4.9 Peer Down Notification. The "Reason" field is defined as one > octet, while the IANA consideration section is defining values as 2-octets > range. This errata suggests updating the IANA registry, instead of the size > of the "Reason" field in the Peer Down Notification message to avoid breaking > existing implementations that use one-octet reason. > ============================== > > This update seems to be a nonsense > > Tom Petch > ________________________________________ > From: GROW <[email protected]> on behalf of The IESG > <[email protected]> > Sent: 21 September 2023 14:29 > To: IETF-Announce > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: [GROW] Last Call: <draft-ietf-grow-bmp-registries-change-03.txt> > (Revision to Registration Procedures for Multiple BMP Registries) to Proposed > Standard > > > The IESG has received a request from the Global Routing Operations WG (grow) > to consider the following document: - 'Revision to Registration Procedures > for Multiple BMP Registries' > <draft-ietf-grow-bmp-registries-change-03.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2023-10-05. Exceptionally, comments may > be sent to [email protected] instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document updates RFC 7854, BGP Monitoring Protocol (BMP) by > making a change to the registration procedures for several > registries. Specifically, any BMP registry with a range of > 32768-65530 designated "Specification Required" has that range re- > designated as "First Come First Served". > > > > > The file can be obtained via > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change/__;!!NEt6yMaO-gk!FLwMLxRv69NjMZrE7Gmros09Z1Hs2O9xtNiwJzefW_Wcc1wCaViUSVRhgO2mUrHbRdLT-ftdEekqaw$ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > GROW mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!FLwMLxRv69NjMZrE7Gmros09Z1Hs2O9xtNiwJzefW_Wcc1wCaViUSVRhgO2mUrHbRdLT-ftWcMWhGg$ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
