[dnsext] a lightweight process for assigning EDNS option codes

Jim Reid <jim@rfc1035.com> Wed, 31 August 2011 07:39 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BFA21F8C39 for <dnsext@ietfa.amsl.com>; Wed, 31 Aug 2011 00:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wmXII4ApHiW for <dnsext@ietfa.amsl.com>; Wed, 31 Aug 2011 00:39:48 -0700 (PDT)
Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F121F8BCD for <dnsext@ietf.org>; Wed, 31 Aug 2011 00:39:48 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id E11FF15420A1; Wed, 31 Aug 2011 08:41:03 +0100 (BST)
Message-Id: <E31D7273-A34E-4DEB-A293-FBAFD536C2E3@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Colm MacCárthaigh <colm@allcosts.net>
In-Reply-To: <CAAF6GDfA3+A+fJz2TY+Jg5WcVWkpAdR8n-4tXMC+zQYe9aGYpw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 31 Aug 2011 08:41:03 +0100
References: <20110830162134.GB84494@shinkuro.com> <CAMbvoa+nh5k8eOA-XRwBD5oxm17+=Q4gCagq0OBS5OEQX=g1sw@mail.gmail.com> <20110831031256.GA98758@shinkuro.com> <CAAF6GDfA3+A+fJz2TY+Jg5WcVWkpAdR8n-4tXMC+zQYe9aGYpw@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: dnsext@ietf.org
Subject: [dnsext] a lightweight process for assigning EDNS option codes
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2011 07:39:48 -0000

On 31 Aug 2011, at 04:23, Colm MacCárthaigh wrote:

> How would you feel about proposing more relaxed registry criteria to
> IANA (by way of an RFC), similar to how the ports registry works?

Sounds like a good idea.

> EDNS0 option codes don't appear to be in much demand, so exhaustion
> isn't as much of a concern.

A process comparable to the one for RRtype code assignment could take  
care of this. The expert review would provide a sanity check and rate  
limiter in case we started burning through EDNS option codes. What if  
marketroids were to decide these are more valuable for vanity purposes  
than new gTLDs?

It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and  
Extended RCODE?) number space for private use and/or experiments just  
like it did for the RRtype, CLASS and RCODE spaces.