Re: [DNSOP] draft-tale-dnsop-edns-clientid

Dave Lawrence <> Tue, 28 March 2017 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9EC91294CD for <>; Tue, 28 Mar 2017 07:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2t2GJqc7dZU2 for <>; Tue, 28 Mar 2017 07:35:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AF551294CA for <>; Tue, 28 Mar 2017 07:35:18 -0700 (PDT)
Received: by (Postfix, from userid 102) id 2DFE23F469; Tue, 28 Mar 2017 10:35:17 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="unknown"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 28 Mar 2017 10:35:17 -0400
From: Dave Lawrence <>
To: Olafur Gudmundsson <>
In-Reply-To: <>
References: <> <>
Archived-At: <>
Subject: Re: [DNSOP] draft-tale-dnsop-edns-clientid
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Mar 2017 14:35:20 -0000

Olafur Gudmundsson writes:
> Strictly speaking the draft was never formally submitted via IANA. 

This is part of the problem with documentation.  At least one natural
entry point for the process, the IANA assignments page, doesn't
indicate how to initiate expert review.

It does link to RFC 6891 and to RFC 3604 Errata, but that's poor
usability even if those documents described how to initiate review,
which they don't.

> As expert I do not have any formal guidelines to tell me how to
> judge options. My rule after implementing ClientSubnet is $,1r|(Bnever
> again$,1r}(B allow complex type.

Agreed that you have poor guidance, the closest thing is from the
RFCs mentioned above, which only says:

  "Assignment of Option Codes should be liberal, but duplicate
   functionality is to be avoided."

I grant that there is reason for pause because both Nominum and
OpenDNS have squatted code points which have duplicate functionality.

There is a larger philosophical discussion that should be had about
this, though, given that it seems to encourage just totally
circumventing IETF/IANA.  It is ironic to me that I was trying to do
the right thing, yet the process which is supposed to have made
getting option code assignments easier and not require action by the
working group has seemingly failed at that task.  The feeling of
failure is exacerbated by not being able to have expectations properly
set by documentation other than "be liberal".

As for whether this is a complex type, that's a whole separate
discussion to have if the draft itself gets more discussion.  Mostly
here in this message I'm focused on process.

> As Expert I do not want to write the rules for myself :-) 
> I will be happy to comment on any suggested rules/advise. 

Fair enough.  Anyone else interested in working on better guidance?
To be clear, I'm totally okay if the result of that is something that
would have still resulted in an initial denial for this option
assignment under Expert Review.  It's the process I want to see