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

Paul Wouters <> Fri, 08 March 2019 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B510127961 for <>; Fri, 8 Mar 2019 06:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SizATVT2slaR for <>; Fri, 8 Mar 2019 06:28:38 -0800 (PST)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E733124B16 for <>; Fri, 8 Mar 2019 06:28:38 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 44G8xb5p5Hz366; Fri, 8 Mar 2019 15:28:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1552055315; bh=aPS75tHoCovPcBJqY6DBC3Pf78QdZOa2Twy6OS1yNLE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gtPJS6lB8oDFTlIIeQuDMsyyEt89AO//Sp8dmbpGYL0IvMutVAWMUD/bGmDPx4+K6 AbQIW2DStznAoMAA1Y94XRXusxdmc2ZAVo8hbA24SCb2K0ROLX852imV7DxiSLkrx+ 6JoGrDJD9EVarbNRrAZ5HuYSBZY/T63GjaU8umaA=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Dbq-rclRIsmm; Fri, 8 Mar 2019 15:28:34 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Fri, 8 Mar 2019 15:28:33 +0100 (CET)
Received: by (Postfix, from userid 1000) id 564885C856; Fri, 8 Mar 2019 09:28:32 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 564885C856
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A26D411601F; Fri, 8 Mar 2019 09:28:32 -0500 (EST)
Date: Fri, 8 Mar 2019 09:28:32 -0500 (EST)
From: Paul Wouters <>
To: Ray Bellis <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Mar 2019 14:28:40 -0000

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.


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