Thomas, On Sun, Mar 23, 2025 at 02:51:24AM +0000, [email protected] wrote: > The sentences are hard to parse.
Sorry for my difficult English. > Let me summarize my current understanding: > > RFC 9515 updated the following BMP registries at IANA from "Specification > Required" to "First Come First Served": > > BMP Statistics Type 32768-65530 > BMP Initiation Information TLVs 32768-65530 > BMP Termination Message TLVs 32768-65530 > BMP Termination Message Reason Codes 32768-65530 > BMP Route Mirroring TLVs 32768-65530 > BMP Route Mirroring Information Codes 32768-65530 > BMP Peer Up Message TLVs 32768-65530 > > That lowers the bar for adding additional information's into the existing > IANA managed BMP message types. See > https://datatracker.ietf.org/doc/html/rfc8126#section-4.4 vs. > https://datatracker.ietf.org/doc/html/rfc8126#section-4.6. This is all correct. > While draft-ietf-grow-bmp-tlv-ebit introduces enterprise managed BMP message > types by suppressing the experimental > (https://datatracker.ietf.org/doc/html/rfc8126#section-4.2) code points of > IANA managed BMP message types. > > Taking https://datatracker.ietf.org/doc/html/rfc7120#section-2 into > consideration, that would mean the following: > > - RFC 9515 enables without an IETF document to add additional information's > to existing BMP message types This continues to be correct. RFC 9515 makes it easy to get FCFS. > - draft-ietf-grow-bmp-tlv-ebit enables enterprises to add additional > information's to existing and future BMP message types > - https://datatracker.ietf.org/doc/html/rfc7120#section-2 governs at which > stage code points from the "Standards Action" range can be allocated > - experimental code point allocation is not supported anymore > > Quoting from: https://datatracker.ietf.org/doc/html/rfc3692#section-1 > > By definition, experimental numbers are not guaranteed to be > unique in any environment other than one where the local system > administrator has chosen to use a particular number for a particular > purpose and can ensure that a particular value is not already in use > for some other purpose. > > We understand that enterprise governed and IANA experimental code points are > very similar. The only difference is that the company who issued the code > point is now identifiable. > > To summarize, both documents together lowers the bar for IANA code point > allocation in above mentioned ranges and enables enterprises to register > their own code points in favor of supporting experimental code points. > > This mechanism has been proven well for IPFIX and experimental code points in > BMP appears to be not being used since introduction of the protocol. > > If I understood correctly you are raising the point wherever the working > group understood that experimental code points are no longer being supported > with draft-ietf-grow-bmp-tlv-ebit anymore and the role of RFC 9515 correct? No. My point is that the FCFS range, in combination with the proposal for ebit, REQUIRES the use of ebit. The fundamental proposal for the ebit draft is the top bit of the uint16 (2 octet field) is now leveraged for "this uses the enterprise encoding". Since the top bit is all values > 32767, this implies that all FCFS code points, if we were to use the ebit rules, MUST use enterprise encoding. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
