Subject: [dnsext] Reserved EDNS0 option codes for private use

From: Matthew Dempsky <[email-masked]>
Date: Fri, 9 Apr 2010 01:47:31 -0700

According to http://www.iana.org/assignments/dns-parameters, there are
no EDNS0 option codes reserved for private use.  As every other 16-bit
DNS parameter reserves 65280--65534 for private use, I suggest the
same range be similarly reserved for EDNS0 option codes.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 12 Apr 2010 15:21:20 -0700

> same range be similarly reserved for EDNS0 option codes.

I've submitted the below draft requesting IANA reserve this range for
private use:

    http://www.ietf.org/id/draft-dempsky-edns0-options-for-private-use-00.txt

Comments?

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 16 Apr 2010 11:21:08 -0700

No one?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 16 Apr 2010 11:33:01 -0700

>    http://www.ietf.org/id/draft-dempsky-edns0-options-for-private-use-00.txt

In general, I think this is a good idea, and should be adopted.
However I would also like to know what the existing IANA practices are
and what level of specification is required to be assigned a number
(e.g. is only a full RFC sufficient? or a public draft alone?).

-- 
Colm

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 16 Apr 2010 12:25:00 -0700

> (e.g. is only a full RFC sufficient? or a public draft alone?).

It varies on a per-registry basis.  Below is the email that I received
when I tried to reserve a range of numbers through the IANA
registration form (which prompted me to post the EDNS0 Options for
Private Use draft).

On Mon, Apr 12, 2010 at 12:02 PM, Amanda Baber via RT
<[email-masked]> wrote:
> Hi Matthew,
>
> DNS EDNS0 Options is a "Specification Required" registry, which means
> that in order to modify it, we need to receive a request that's
> supported by a permanent and readily available reference, as
> described in RFC 5226, which in turn must be approved by an
> IESG-designated expert.
>
> The people to talk to about this idea would actually be the IETF's
> DNSEXT Working Group, which was responsible for the RFC that defines
> this registry. Contact information for the DNSEXT WG is available here:
>
> http://datatracker.ietf.org/wg/dnsext/charter/
>
> Best regards,
>
> Amanda Baber
> Internet Assigned Numbers Authority
> ICANN

---

From: Edward Lewis <[email-masked]>
Date: Fri, 16 Apr 2010 15:26:05 -0400

>(e.g. is only a full RFC sufficient? or a public draft alone?).

From RFC 2671 (heavily cropped to focus on Option code):

# 7 - IANA Considerations
...
#     It is the recommendation of this document and its working group
#     that IANA create a registry for EDNS Extended Label Types, for EDNS
#     Option Codes, and for EDNS Version Numbers.
...
#     any published RFC (including Informational, Experimental, or BCP)
#     should be grounds for allocation of an EDNS Option Code.

That is IANA's official instructions.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?

---

From: David Ulevitch <[email-masked]>
Date: Fri, 16 Apr 2010 15:05:38 -0700

> That is IANA's official instructions.

Yep, and that should change to make it easier.  Or at the very least,
allow a reserved range for private use.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 16 Apr 2010 18:25:16 -0400

> That is IANA's official instructions.

And IANA ignored the instructions :-)
I had the registries created around the time of the DO bit and NSID
RFC's.

	Olafur

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Apr 2010 23:57:48 +0000

> Date: Fri, 16 Apr 2010 11:21:08 -0700
> From: Matthew Dempsky <[email-masked]>
> 
> No one?

i am uncomfortable with private code point ranges in general.  i didn't
oppose it for rr type codes and i won't oppose it for edns0 option codes.
but i sure hope that somebody else will (oppose it).

---

From: Paul Vixie <[email-masked]>
Date: Sat, 17 Apr 2010 00:14:11 +0000

> Date: Fri, 16 Apr 2010 15:05:38 -0700
> From: David Ulevitch <[email-masked]>
> 

2671 says that noone can be denied but they have to document their blobs
in RFC's, which can be individual submissions that do not require consensus.

how much easier would you like it to be, and why?

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 16 Apr 2010 19:33:58 -0700

> how much easier would you like it to be, and why?

My opinion depends mostly on what the current distinction of "on-hold"
vs "standard" vs "reserved" in the IANA registry means.  Of the 4
options currently assigned by IANA, 2 are named and on-hold, 1 is
named and standard, and 1 is simply reserved.  Further, of these, only
one is RFC assigned, whereas the other three are mere drafts (and
expired at that).

If, as my understanding suggests, those four values are all truly
assigned, hold more or less equal weight, and will not be (at least
without serious consideration for backwards compatibility)
reappropriated later, then I'm happy with the current IANA procedure.

That said, I still think there's merit to reserving a range of values
for private use.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 17 Apr 2010 05:28:56 +0000

> Date: Fri, 16 Apr 2010 19:33:58 -0700
> without serious consideration for backwards compatibility) reappropriated
> later, then I'm happy with the current IANA procedure.

that's my understanding.

> That said, I still think there's merit to reserving a range of values

why?

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 16 Apr 2010 23:17:59 -0700

>> later, then I'm happy with the current IANA procedure.

Cool, good to know.

>> That said, I still think there's merit to reserving a range of values

So an example would be right now with edns-client-ip.  I'd like to be
experimenting with it and getting some operational experience, but no
code point has been assigned yet.  Fortunately, the allocation rules
for the EDNS0 Option registry is loose enough that IANA could already
assign a code for use, but the protocol (in particular, the wire
format) isn't fully solidified yet. So what happens when -01 is
released and isn't compatible with -00?  Or when -02 isn't compatible
with either, etc?

The best solution I see is for experimenters to make pairwise
agreements using new private option codes for each incompatible change
until the protocol extension has stabilized, and then start using an
IANA assigned code.  Otherwise you risk either compatibility issues as
experimenters independently revise their software, or polluting the
registry with assignments that will most likely be short lived.
(Perhaps there's a way to 'garbage collect' these assignments later,
but I'm concerned about how well positioned IANA is to do this; at
least private parties are in a position to know which private codes
they're actually using.)

---

From: Paul Vixie <[email-masked]>
Date: Sat, 17 Apr 2010 06:46:52 +0000

> Date: Fri, 16 Apr 2010 23:17:59 -0700
> code point has been assigned yet.  Fortunately, the allocation rules for
> the EDNS0 Option registry is loose enough that IANA could already assign
> a code for use, but the protocol (in particular, the wire format) isn't
> fully solidified yet. So what happens when -01 is released and isn't
> compatible with -00?  Or when -02 isn't compatible with either, etc?

i see the problem.

> The best solution I see is for experimenters to make pairwise agreements
> using new private option codes for each incompatible change until the
> protocol extension has stabilized, and then start using an IANA assigned
> code.  Otherwise you risk either compatibility issues as experimenters
> independently revise their software, or polluting the registry with
> assignments that will most likely be short lived.  (Perhaps there's a way
> to 'garbage collect' these assignments later, but I'm concerned about how
> well positioned IANA is to do this; at least private parties are in a
> position to know which private codes they're actually using.)

ietf isn't well set up for incremental experimentation.  that should change.
you should be able to publish a draft, spend no more than a couple of weeks
getting "experimental consensus" on it, and then have it posted as an RFC
with an "experimental codepoint" or "experimental codepoint range".  when
you get done trying out ideas and you have something that you and your
pairwise buddies all like, you should be able to publish a draft and have
it either adopted (put on the standards track) or published as a bcp or
experimental, with a (new) codepoint assigned.

all of which is 2.5 orders of magnitude than ietf's wheels can currently
spin.  and on that lone basis i can understand why a private range makes
sense.  but from iab's standpoint it would be better to fix the process so
that a private range wasn't needed, than to reserve a private range.  for
one thing it would enable robust open experimentation, and for another
thing it would rule out the possibility that once opendns and google and
akamai all privately agreed on what they wanted and how it should work they
would stop trying to publish the results openly since their business problem
had already been solved.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 17 Apr 2010 11:16:47 -0400

At 23:17 -0700 4/16/10, Matthew Dempsky wrote:

>I'd like to be

You are raising an issue that has lingered for a long time.  A while 
back it was over the assignment of resource record types, and the 
trouble with TXT records.  (In the expired MARID WG, SPF vs. TXT wars 
for one.)

You are right in what you want to do.  And your observation is right 
too.  To adequately test something, you need to release it into the 
wild.  If you don't assign a good number and the idea catches fire, 
it's too late to renumber.  But if it dies on the vine then you've 
assigned a good number, the number is marked for life.  Because 
there's always someone somewhere that will claim that the idea is 
being used in some village somewhere out in the plains.

>but I'm concerned about how well positioned IANA is to do this; at

I wish there was too, but it's not entirely IANA's fault.  The IETF 
could direct IANA to return a value to the available space but there 
is always reluctance.

>least private parties are in a position to know which private codes

In some cases, using private types would be a good idea before 
writing up the ideas to result in a real IANA assignment.

(But, there's got to be a better way...I mean to the general 
management of registry assignments.)

---

From: [email-masked]
Date: Mon, 19 Apr 2010 18:03:47 +0000

> trouble with TXT records.  (In the expired MARID WG, SPF vs. TXT wars 
[wonderful prose elided]

> Edward Lewis

	back in  the mysts of time, a credible proposal (an ID even)
would merit the assignment of a code point with the IANA.  This model
has much to its credit.  However, over time, it was deemed reasonable
to withhold code points for a variety of reasons... not all of them
sane or credible.  And today we are in this wonderful situation where
it is often easier/simpler to just "pick" a code point and run with
it.  

Paul Vixies plan, to release with testpoints and then when proven
successful, -re- release with "real" code points is not credible
given software refresh cycles by endusers.  

--bill

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Apr 2010 14:37:05 -0700

> given software refresh cycles by endusers.
SPF and Sender-ID have incompatible semantics for the same TXT RR.  
There were no new code points or label prefixes.  Utilizing the _same_ 
preamble within the TXT RR allowed claims of higher adoption rates for 
either use, with loss of clarity of which message element use had been 
authorized (not authenticated).

There was no shortage of TXT RR preambles since TXT RR preambles have no 
registry.  There does not appear to be any easy way to overcome 
limitations imposed by proprietary environments that might make it 
difficult to introduce new RR types, or a means to avoid two groups 
claiming to have defined semantics for identical resources and to be 
thereby leading the parade.

If there had been code points defined as private, the IETF may have had 
an opportunity to subsequently ensure adoption of separate non-private 
code points for records having different semantics.

-Doug

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 19 Apr 2010 16:52:50 -0700

On Mon, Apr 19, 2010 at 2:37 PM, Douglas Otis <[email-masked]> wrote:
> If there had been code points defined as private, the IETF may have had an
> opportunity to subsequently ensure adoption of separate non-private code
> points for records having different semantics.

Well, there's already a reserved range of code points for private RR
types.  I think the reasoning for going with TXT records was a matter
of tools support for provisioning new resource records.  Most web
interfaces that I've used support the standard types (e.g., always A,
NS, MX, CNAME, maybe AAAA, TXT, SRV), but I've never seen a web
interface with support for entering the equivalent of generic TYPEnn
records.

However, this is somewhat off topic.  The motivating issue at hand was
simply that EDNS0 Option Codes have no reserved range of values for
private use (unlike DNS classes, RR types, and even RCODEs, which each
have private use ranges).