Hi Eric, > What happens when two deployments independently select the same > experiment code point with different semantics? Is there some way to > detect that, or do they just get confused? This seems like it it's fine in a > closed environment, but unless I'm missing something, there's nothing > in this text that actually requires that.
You might spend some time reading about experimental codepoints and the experiments they are used for in BCP 82 (specifically RFC 3692). There it 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 [sic] 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. ...and further... 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. This document makes clear reference to 3692 from the introduction suggesting that readers look there for an explanation of Experimental codepoints. The purpose of this document is to adjust the registries to allow experimentation, not to redefine or refine the meaning of Experimental codepoints. We do draw out the security concern that we think 3692 glossed over, but this is a reminder to protocol specs or implementers that they must watch out. This is not a protocol spec and doesn't need to describe how implementations handle conflicts. Ciao, Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
