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 <ietfc@xxxxxxxxxxxxx> 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 <grow-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx> > Sent: 21 September 2023 14:29 > To: IETF-Announce > Cc: grow-chairs@xxxxxxxx; grow@xxxxxxxx; warren@xxxxxxxxxx; draft-ietf-grow-bmp-registries-change@xxxxxxxx > 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 > last-call@xxxxxxxx mailing lists by 2023-10-05. Exceptionally, comments may > be sent to iesg@xxxxxxxx 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 > GROW@xxxxxxxx > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!FLwMLxRv69NjMZrE7Gmros09Z1Hs2O9xtNiwJzefW_Wcc1wCaViUSVRhgO2mUrHbRdLT-ftWcMWhGg$ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
