Dear Jeff, The sentences are hard to parse. 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. 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 - 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? My response: draft-ietf-grow-bmp-tlv-ebit anymore and RFC 9515 are complementary and together setting with RFC7120 the right setting for managing codepoints in BMP. Quoting from: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-ebit-06#section-3.3 Of these, the Experimental values are being suppressed in favor of using the E-bit mechanism described in this document; Should this be mentioned Section 1 in the document to make it more evident? Best wishes Thomas -----Original Message----- From: Jeffrey Haas <[email protected]> Sent: Saturday, March 22, 2025 6:36 AM To: [email protected]; [email protected] Subject: [GROW] bmp ebit and rfc 9515 Be aware: This is an external email. As I'm glancing through the ebit draft, it occurs to me that the changes to RFC 9515 have a potentially perverse interaction with it: All new FCFS fields are now required to use the ebit. This would include the experimental ranges. I had noted a prior set of emails last year from Ahmed when this bit of interaction occurred to me. This isn't necessarily a bad thing. But it does have the interesting property that if grow doesn't want some vendor's PEN stuck in something forever for a feature that might be popular, it means that "early adoption" from the standards point becomes almost a required thing. The WG should ponder if this is a set of properties it's really wanting and, if so, the ebit document should call it out explicitly as an interaciton with RFC 9515. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
