On Jun 10, 2025, at 4:22 PM, Carlos Pignataro <cpign...@gmail.com> wrote:
> 3. I recommend adding an Experimental range > https://datatracker.ietf.org/doc/html/rfc8126#section-4.2 To quote that section: Experimental Use is similar to Private Use, but with the purpose being to facilitate experimentation. See [RFC3692] for details. IANA does not record assignments from registries or ranges with this policy (and therefore there is no need for IANA to review them) and assignments are not generally useful for broad interoperability. Unless the registry explicitly allows it, it is not appropriate for documents to select explicit values from registries or ranges with this policy. Specific experiments will select a value to use during the experiment. When code points are set aside for Experimental Use, it's important to make clear any expected restrictions on experimental scope. For example, say whether it's acceptable to run experiments using those code points over the open Internet or whether such experiments should be confined to more closed environments. See [RFC6994] for an example of such considerations. The abstract of RFC 3692 says: When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. I'm not sure what an experiment with a link-layer header type would be. The two possibilities I can see are: 1) you're experimenting with a new link layer, and want a LINKTYPE_ to use when recording traffic over that link layer; 2) you're experimenting with an existing link layer that lacks a LINKTYPE_ value, and are testing various options to see how well they work in libpcap/tcpdump/Wireshark/etc.. RFC 3692 says Numbers in the experimentation range are similar to those called "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be required to explicitly enable the experimental feature and likewise have the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the end user can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will. RFC 2434's description of "Private Use" is Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability. Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. "X-foo:" header lines in email messages. so it sounds as if the difference between "private" and "experimental" use is that private use is for internal use in production and experimental use is for internal use when doing experiments, i.e. if you grab a value for private use you're probably going to use it consistently in your organization and not change its definition arbitrarily, whereas if you grab a value for experimental use you may change its definition as a result of your experiments. So, yes, we could assign a range for it. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
