Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Wouters <[e-mail]>]

On Fri, 8 Mar 2019, Ray Bellis wrote:

> 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.

So you need to know the semantics of this even if each endpoint can decide
in their own way what to do with that information. Sounds like it should
use a code point ideally with a specification.

> 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.

But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf software". These different vendors must
understand the meaning of the opaque data even if their functionality
can be non-standard.

> Please also note that the requirements for assignment of an EDNS option is 
> "Expert Review".  It does *not* require a Standards Track RFC.

Let's hope the Expert is reading these emails. I would hope they have
similar concerns.

> It's therefore none of DNSOP's business what the values of those tags are,

See above. I disagree.

> nor what the resulting packet processing decisions will be.

Agreed.

> As far as the *protocol* is concerned, they're opaque.

It seems you want to make decisions based on the blob content, so the
protocol functioning _is_ involved. At least vendors need to know what
the blob means.

> It's not even any of DNSOP's business how large that blob is

Again, I disagree. You want to both have it working in different
software vendors while not defining the blobs at all. Interoperability
quacks like a DNS standard to me.

> , but the current 
> 16-bit limit is a concession (or some might say appeasement) to the perceived 
> privacy concerns.

I'm glad to hear you are taking Privacy Considerations into account.

> 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.

I'm confused why and how you would want multiple vendors to implement the same
opague blob interpretation without a standard.

Sure you can get a code point without RFC, but if you plan to use that
for some standarized interoperability thing, I would hope the DNS
vendors would balk and ask you to write a document for this.

Paul