Re: [DNSOP] draft-tale-dnsop-edns-clientid
Dave Lawrence <tale@dd.org> Tue, 28 March 2017 14:35 UTC
Return-Path: <tale@dd.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EC91294CD for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 07:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t2GJqc7dZU2 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 07:35:18 -0700 (PDT)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF551294CA for <dnsop@ietf.org>; Tue, 28 Mar 2017 07:35:18 -0700 (PDT)
Received: by gro.dd.org (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: <22746.29861.99723.209867@gro.dd.org>
Date: Tue, 28 Mar 2017 10:35:17 -0400
From: Dave Lawrence <tale@dd.org>
To: Olafur Gudmundsson <ogud@ogud.com>
Cc: dnsop@ietf.org
In-Reply-To: <3BE34823-E83C-4F9D-ABE1-35C61F9E2996@ogud.com>
References: <22745.38650.113925.208670@gro.dd.org> <3BE34823-E83C-4F9D-ABE1-35C61F9E2996@ogud.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vlpzUbmGLYV3a7EXBWLU2rxNKlw>
Subject: Re: [DNSOP] draft-tale-dnsop-edns-clientid
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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. https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11 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 improved.
- [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Olafur Gudmundsson
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Ray Bellis
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Peter van Dijk
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Peter van Dijk
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Barry Raveendran Greene
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Ray Bellis
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Ray Bellis
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Bob Harold
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Ray Bellis
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Dave Lawrence
- Re: [DNSOP] draft-tale-dnsop-edns-clientid tjw ietf
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Mark Andrews
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Ray Bellis
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Peter van Dijk
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Peter van Dijk
- Re: [DNSOP] draft-tale-dnsop-edns-clientid Peter van Dijk