> So, yes, we could assign a range for it. Thanks for this, Guy.
Based on my experience, providing Experimental allocations encourages experimenters to use designated values rather than pulling from unassigned public ranges, which can lead to leaks or collisions. Carlos. > On Jun 10, 2025, at 8:38 PM, Guy Harris <[email protected]> wrote: > > On Jun 10, 2025, at 4:22 PM, Carlos Pignataro <[email protected]> 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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
