On 08/03/2019 03:58, Paul Wouters wrote:
If you have a specific use case, get a code point for that specific use case. Than you know for sure what the blob means and that it will be interpreted by all parties in the same standard RFC way.
I have some generic use cases in mind (subject to the existing cautions about bilateral agreements, consenting adults, etc) and also a very specific use case.
I have customers that want to tag a packet received by a DNS load-balancer and then on the back-end server use that tag to make decisions about the processing of that packet.
They want to do that with heterogenous off-the-shelf software, which means that implementations have to agree which code point to use. This strongly suggests requesting an *assigned* code point.
Please also note that the requirements for assignment of an EDNS option is "Expert Review". It does *not* require a Standards Track RFC.
It's therefore none of DNSOP's business what the values of those tags are, nor what the resulting packet processing decisions will be. As far as the *protocol* is concerned, they're opaque.
It's not even any of DNSOP's business how large that blob is, but the current 16-bit limit is a concession (or some might say appeasement) to the perceived privacy concerns.
So while not requiring an RFC to obtain an assignment, the I-D is published for feedback on the design aspects of the option and to act as the reference specification for it.
Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
