Hello Ray,
On 8 Mar 2019, at 11:33, Ray Bellis wrote:
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.
Me too, and I’ve spoken to several other people who also have such
needs. I bet dnsdist users would eat this up if we implemented it.
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.
Well said!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
