Subject: DNSEXT WGLC: RFC2929bis

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 10 Aug 2006 23:21:21 -0400

Since I posted draft-ietf-dnsext-2929bis-03.txt, two things have
occurred to me about section 3.1, RRTYPE IANA Considerations:

(1) After the DNSEXT meeting in Montreal I claimed that part of the
RRTYPE range was still Specification Required. This is incorrect. There
was an earlier version of the draft which did have some RRTYPE ranges
allocated based on a special policy and some based on Specification
Required but this is not true of the current draft. While some
Specification Required range could be added back, this seems like an
unnecessary complication since an expert is needed to determine whether
a specification is adequate in any case. I am included to leave the
draft as is in this regard.

(2) CLASSes. Admittedly, allocation of RRTYPEs in new CLASSes does not
seem to be a pressing problem right now but there has been some renewed
talk of the use of new CLASSes. In any case, the problem is that the
basic DNS documents make it clear that some RRTYPEs are defines across
all CLASSes (SOA, AXFR, CNAME, DNSKEY, TSIG, ...) while others are CLASS
specific and their RRTYPE code point could mean something completely
different in another CLASS (A, AAAA, A6, WKS, ...). Given the very low
utilization rate for the RRTYPE space, it seems like it would not cost
much to specify some ranges for cross CLASS RRTYPEs and some for CLASS
specific RRTYPEs. If someone does get a CLASS allocated, it would seem
that they should be able to set their own policy for allocation of CLASS
specific RRTYPEs (although they could, of course, incorporate 2929bis by
reference) but that 2929bis should govern for all cross CLASS RRTYPES.
	So, I suggest the substitute section 3.1 below. This includes
allowance for TA and DLV as mentioned, I believe, in another WGLC
comment, replacement of "RR TYPE" by "RRTYPE" and provision for separate
ranges for cross CLASS and IN CLASS specific RRTYPEs. Note that it
really isn't a problem, as long as there are enough RRTYPE codes, if an
IN CLASS specific RRTYPE is allocated from the cross CLASS range. There
is only a problem is someone who gets a CLASS allocation tries to
allocate an RRTYPE specific to their CLASS from the cross CLASS range.
	Note: a plus sign in the second column indicates new/changed
text. All other text is the same.

Thanks,
Donald

3.1 RRTYPE IANA Considerations

   There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs,
   and MetaTYPEs.

   Data TYPEs are the primary means of storing data.  QTYPEs can only be
   used in queries.  Meta-TYPEs designate transient data associated with
   a particular DNS message and in some cases can also be used in
   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
   the block from 100 through 103 while Q and Meta Types have been
   assigned from 255 downwards except for the OPT Meta-RR which is
   assigned TYPE 41.  There have been DNS implementations which made
   caching decisions based on the top bit of the bottom byte of the RR
   TYPE.

   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
   [RFC 2845], and TKEY [RFC 2930].

   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
   AXFR, and IXFR.

 + There is also an orthogonal division of RRTYPEs into those which have
 + the same meaning across all CLASSes and those which are CLASS
 + specific and whose RRTYPE value might have different meanings in
 + different CLASSes.

 + Considerations for the allocation of new cross CLASS RRTYPEs and new
 + IN (Internet) CLASS RRTYPEs are given below. Allocation policies for
 + CLASS specific RRTYPEs in other CLASSes may differ but are
 + constrained to the CLASS specific ranges given below. In cases where
 + it is not clear if an RRTYPE will be IN CLASS specific or cross CLASS
 + it is safest to assign a code point as if it will be cross CLASS.

     Decimal
   Hexadecimal

     0
   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
          2931, 4034] and in other circumstances and must never be
 +        allocated for ordinary use in any CLASS.

     1 - 127
   0x0001 - 0x007F - remaining TYPEs in this range are assigned for
 +        cross CLASS data TYPEs by the DNS TYPE Allocation Policy as
 +        specified in section 3.1.1.

     128 - 255
   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for
 +        cross CLASS Q and Meta TYPEs by the DNS TYPE Allocation
 +        Policy as specified in section 3.1.1.

 +   256 - 16,383
 + 0x0100 - 0x3FFF - assigned for IN CLASS specific data TYPEs by the
 +        DNS TYPE Allocation Policy as specified in section 3.1.1.

 +   16,384 - 32,767
 + 0x4000 - 0x7FFF - assigned for IN CLASS specific Q or Meta TYPEs
 +        TYPEs by the DNS TYPE Allocation Policy as specified in
 +        section 3.1.1.

 +   32,768 - 49.151
 + 0x8000 - 0xBFFF - remaining types in this range assigned for cross
 +        CLASS data TYPEs by the DNS TYPE Allocation Policy as
 +        specified in section 3.1.1.

 +   49,152 - 65,279
 + 0xC000 - 0xFEFF - assigned for cross CLASS Q or Meta TYPEs by the
 +        DNS TYPE Allocation Policy as specified in section 3.1.1.

     65,280 - 65,534
   0xFF00 - 0xFFFE - Private Use.

     65,535
   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Aug 2006 11:09:24 -0400

Ed's lunatic fringe comment for the day...

>occurred to me about section 3.1, RRTYPE IANA Considerations:

I don't mean to shoot the messenger, but I want to register my stance 
that I no longer have been following this document.  More or less, 
the discussion has gotten too wrapped around the bureaucratic axle 
for my taste.  This isn't a reflection on Donald, it's a reflection 
on how much time we spend making rules in the IETF.

'Course, saying that isn't worth a message on it's own.

>talk of the use of new CLASSes. In any case, the problem is that the

I'm curious what this renewed interests in CLASS is.  Perhaps another 
thread could be started about that if anyone is willing spill the 
beans.

The reason I'm surprised is that having the CLASS field after the 
labels means you have to know how to interpret the labels regardless 
of class.  I.e., you can't define a different label syntax for a new 
class, no "IDN Class" to the rescue.  CLASS is even after TYPE, so 
it's not useful for the syntax of that either.  I can't think of a 
reason for the CLASS these days.

>ranges for cross CLASS and IN CLASS specific RRTYPEs. Note that it

Given lessons in routing and IP address ranges, addressing and 
netmasks, and the misplacement of the OPT RR already, I suspect that 
declaring ranges of special meanings is an unnecessary complication. 
Maybe in code it's easier to not have to check the class is the type 
is less than 23134, but you still have to test even for that.

Maybe it would be more efficient (parameter allocation wise) to just 
merge the CLASS and TYPE fields into one 32 bit number.  Rats - TYPE 
comes before CLASS on the wire.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 12 Aug 2006 14:08:35 -0400

Hi Bill,

See below at @@@

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Saturday, August 12, 2006 10:38 AM
To: Eastlake III Donald-LDE008
Cc: Edward Lewis; [email-masked]
Subject: Re: DNSEXT WGLC: RFC2929bis

 lets see...  

	) one does not need a new class to have their own root serves.
:)

@@@ Of course there are a bunch of details and assumptions in my
statement that I thought it would be tedious to spell out. If you don't
care about access to the generally accepted IN CLASS DNS tree and/or
don't care about following the original DNS design and/or are willing to
implement enough special case kludgery, there are several ways you can
have your own root servers.

	) i'm with Ed on the fact that this document (and by extention
the WG)
	  is obsesed with process.

@@@ There is some justification for being a bit more rigid about process
in the DNSEXT WG because the DNS is such a magnet for controversy. As
for this particular document, it is inevitably entirely about process.
Why? Because, meaning no disrespect, IANA is now a clerk, not an expert,
so the process by which this clerk makes decisions (frequently with the
aid of others) on code point assignments needs to be specified.

                                   the presumption that a third party
designated
	  expert is in fact able to weigh in on a design/implementation
and "bless"
	  it seems a bit odd.    One might ask who the DE was for the
PTR, A, and 
	  NS records?   

@@@ I should think it would just seem traditional rather than "odd". Jon
Postel was the universal "designated expert" when I first become active
in the IETF and I think that worked well. I wasn't around early enough
to see basic things like PTR, A, or NS defined, but I would assume that
it was Jon Postel.

	  if we -want- to slow down process and give credence to the
claims that it
	  takes undue time to advance changes to the DNS, then by all
means, advance
	  this document.  

@@@ Why do you think the process in this document would be slower or
worse than the current process? As far as I can tell, the consensus of
the DNSEXT working group, with which I agree, is that this is a
liberalization that will make change easier. Most of the motivation for
this document is to make it easier, in some cases, to get RRTYPE
assignments.

@@@ Donald

-- bill (welcoming Ed's periodic visits to his neighborhood)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Aug 2006 11:14:04 -0400

>this document is to make it easier, in some cases, to get RRTYPE

Being non-specific, the DNSEXT WG is comprised of engineers and not 
bureaucrats.  You might think that this is a point of pride, but it's 
also a point of weakness.  It's the same as having this group try to 
debate the legal issues of liability of signing a zone in DNSSEC - we 
are also not lawyers.

That's why I feel that parts of the document, specifically the number 
ranges, may be overkill.  We are over engineering a bureaucratic 
process.  The result will be poorer performance of the bureaucracy 
(via higher staffing costs or slower response time, for example).

Does the OPT RR's type code value of 41 hurt implementations?  I ask 
because it was mistakenly assigned that instead of a meta-RR number 
(like 25x I think?).  If history says it has not been a problem, 
let's drop the stratification of the numbers.  Let's streamline the 
bureaucracy.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Aug 2006 10:38:20 -0700

I agree, if you differentiate numbers you will have people asking for a second number just so that they look 'official'.

We went through this with X-Headers and X-Content types and in the end realized that it was a bad idea. They are just numbers. Encoding semantics into them is a bad idea. Encoding political semantics into them is worse.

The simpler the procedure the less IANA has to do.

Also consider the fact that DNSEXT is chartered with a finite life span. Closing WGs is a good thing. It represents the strongest statement that the IETF can make that work is finished. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Wednesday, August 16, 2006 11:14 AM
> Cc: [email-masked]
> Subject: RE: DNSEXT WGLC: RFC2929bis
> 
> Being non-specific, the DNSEXT WG is comprised of engineers 
> and not bureaucrats.  You might think that this is a point of 
> pride, but it's also a point of weakness.  It's the same as 
> having this group try to debate the legal issues of liability 
> of signing a zone in DNSSEC - we are also not lawyers.
> 
> That's why I feel that parts of the document, specifically 
> the number ranges, may be overkill.  We are over engineering 
> a bureaucratic process.  The result will be poorer 
> performance of the bureaucracy (via higher staffing costs or 
> slower response time, for example).
> 
> Does the OPT RR's type code value of 41 hurt implementations? 
>  I ask because it was mistakenly assigned that instead of a 
> meta-RR number (like 25x I think?).  If history says it has 
> not been a problem, let's drop the stratification of the 
> numbers.  Let's streamline the bureaucracy.
> 
> --

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 18 Aug 2006 17:35:20 -0400

Hi Ed,

Thanks for your message below, it has made me think more about some
aspects of this...

See below at ### 

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]] 
Sent: Wednesday, August 16, 2006 11:14 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: DNSEXT WGLC: RFC2929bis

### I don't think there is much similarity. Although there are (nice)
people involved, so a finite error rate is only to be expected, the
whole idea of IANA Considerations is to make the decisions required of
IANA to be mechanistic, objective decisions. That is certainly amenable
to engineering and has nothing to do with legal issues which changes
with the constantly shifting human judgment of judges.

That's why I feel that parts of the document, specifically the number
ranges, may be overkill.  We are over engineering a bureaucratic
process.  The result will be poorer performance of the bureaucracy (via
higher staffing costs or slower response time, for example).

### As I see it, the relevant questions are is there technical utility
in a distinction, like data versus non-data RRTYPEs, and how hard is it
to make IANA's decision mechanistic. I believe there is substantial
utility, if we want the DNS to be able to handle unknown RRs, so DNS
software which doesn't understand the RRTYPE has an independent way of
telling whether it should cache the RR. And IANA's decision criterion
would have been trivial if RFC 2929 had simply required any I-D IANA
Considerations section that allocated an RRTYPE to clearly state if it
was a data or non-data RRTYPE and similarly for any other document being
used for a 'Specification Required' RRTYPE allocation. In fact, I would
argue that IANA should really have insisted on such a provision in RFC
2929 to avoid the existing situation where IANA might have to do some
technical analysis of the specification to make the data versus non-data
distinction. Part of the idea of proper IANA Considerations is to avoid
such a burden on IANA. I think that, for RRTYPEs, 2929bis solves this
problem in a different way by putting a DNS Expert in the loop who will
be able to determine this. 

### If things are set up properly (properly "engineered") it should make
little different to IANA how many categories of RRTYPEs there are unless
IANA has to do some analysis, an alternative which fundamentally doesn't
work. If IANA Considerations sections that allocate an RRTYPE were
required to clearly specify the category, when IANA works on such a
document they just pick up the category and assign an RRTYPE from that
category or bounce the document back for more information.
Alternatively, if an expert is going to look at the specification, they
should be recommending a number form the right category for the RRTYPE
to IANA. If the specification is so opaque the expert can't figure out
if it is a data or non-data RR, they should reject it out of hand.

Does the OPT RR's type code value of 41 hurt implementations?  I ask
because it was mistakenly assigned that instead of a meta-RR number
(like 25x I think?).  If history says it has not been a problem, let's
drop the stratification of the numbers.  Let's streamline the
bureaucracy.

### I do not see how that follows. So there was one case where giving a
meta-RR a number from the data-RR range did not cause a problem. Why
does this imply that it is just fine to make it inherently impossible
for future DNS software to tell whether an unknown RR is a data RR which
should be cached or a non-data RR which shouldn't?  Among other things,
OPT overloads the CLASS field with the sender's UDP payload size limit
and is supposed to always have root as the owner name, so even if it
were cached, it seems very unlikely to cause problems. Who knows what
owner name or other characteristic future unknown meta-RRs will have? 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-
Edward Lewis
+1-571-434-5468
NeuStar

### Thanks,
### Donald

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 20 Aug 2006 23:51:47 -0400

Hi Phil,

See below at ###

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Wednesday, August 16, 2006 1:38 PM
To: Edward Lewis; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: DNSEXT WGLC: RFC2929bis

I agree, if you differentiate numbers you will have people asking for a
second number just so that they look 'official'.

### There has long been a difference in DNS between data-RRs and
non-data-RRs. Since, as far as I know, no one has asked for one of each
just to look 'official', I don't understand why this would start now.
RRTYPEs are generally invisible to the user. The user just asks for
something that takes some lookup in the DNS and has no knowledge of
what's happening under the covers in terms of RRTYPEs. I believe you are
making a highly inappropriate extrapolation from domain names, which are
user visible.

We went through this with X-Headers and X-Content types and in the end
realized that it was a bad idea. They are just numbers. Encoding
semantics into them is a bad idea. Encoding political semantics into
them is worse.

### Who is talking about encoding political semantics into RRTYPE code
points?

### If there are two inherently different types, like RRs that should be
cached and RRs that should not be cached, and you want to be able to
deal with unknown future allocated RRs, then distinguishing them is the
right thing. If this were clearly foreseen when the DNS was designed,
then maybe instead of a 16 bit RRTYPE field, this would be a 1 bit
'cacheable' subfield and a 15 bit number subfield. But as it is, we are
stuck with something not quite so clean. People who would know better
than I would say there are servers that will not cache RRs in the
128-255 range, most of which are unallocated. Claiming RRTYPE code
points are all alike and allowing these to be assigned for data-RRs that
should be cached seems like a recipe for serious problems.

### I think it is wrong to think only of simplicity. The most important
goal of IANA Considerations is that it not involve judgment or technical
expertise on the part of the IANA clerical staff. I don't think it would
matter if there were 2, 4, or 64 categories of RRTYPEs, as long as there
was a sound technical reason for the categories and, most important, it
was a purely mechanical task for IANA to know which category to use,
such as requiring the IANA Considerations section that allocates a new
value to state the category or having IANA be informed by a Designated
Expert what category to use.

Also consider the fact that DNSEXT is chartered with a finite life span.
Closing WGs is a good thing. It represents the strongest statement that
the IETF can make that work is finished. 

### I can't figure out what this has to do with any of these questions.
Of course DNSEXT will get closed sometime. That's why RFC 2929 and the
2929bis draft do not assign it any role whatsoever in making
assignments.

### Thanks,
### Donald

>  I ask because it was mistakenly assigned that instead of a meta-RR 
> number (like 25x I think?).  If history says it has not been a 
> problem, let's drop the stratification of the numbers.  Let's 
> streamline the bureaucracy.
> 
> --
> Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard 
> time catching on in North America.
> 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in a 
> single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Aug 2006 08:18:14 -0400

At 16:27 -0400 8/18/06, Eastlake III Donald-LDE008 wrote:

>### If you are asking about interest in general, the only recent spurt I
>can think of off hand related to internationalization.

To those who followed that effort - using a separate class for 
non-ASCII names is pretty much dead, right?

>### I never claimed this proposed change was terribly important but
>unless we are going to rewrite the fundamentals of DNS, why not take
>them into account? The provisions I'm talking about affect allocation

Why not - because taking time to define rules and solutions to 
problems that don't exist is a waste of time.

>which is exactly the topic of 2929bis. If they were adopted, things
>would be fine if someone did get a CLASS allocation and wanted to use it
>for their own thing. If we don't adopt this simple change and someone
>gets a CLASS allocation, you would probably end up having to update
>2929bis.

There's a point when you begin throwing good money after bad.  I 
think the CLASS concept has proven to be bad money.  Perhaps it had a 
good intent, but a pragmatic look says it has failed.

>several ways you can have your own root servers." But CLASS is the
>intended way to have your own tree completely under the control of your
>own root while still having access to the generally accepted IN tree.

It's not that you can't do this, it's that no one does it.  If the 
IETF is to avoid becoming "irrelevant" then we need to keep in mind 
how the protocols are being used vs. what they were designed to do in 
the 80's and 90's.

My point being, backing up to 2929bis, is that we are 
over-engineering a task we  wish to make a simple bureaucratic step. 
This is a case of trying to solve a problem that just doesn't exist 
in nature.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Aug 2006 08:44:35 -0400

>with the constantly shifting human judgment of judges.

My point is not that there's a legal element to this.  My point is 
that engineers are as bad at bureaucracy as they are bad at legal 
matters.

>IANA has to do some analysis, an alternative which fundamentally doesn't

Cross-my-eyes and furrowing-my-brow...if there was just one bin for 
all requests, there isn't room for analysis.  If we create bins to 
take away the need for analysis, then the bureaucracy has to analyze 
the request to know where to bin it.

When you go to an old time DVD store, do you look for "The Blues 
Brothers" in the musical or comedy section?  It's easier if the store 
just lines the titles up alphabetically.

>meta-RR a number from the data-RR range did not cause a problem. Why

I see a score of "The type value doesn't matter" of 1, "the type 
value is does matter" of 0.  Is the stratification of type codes a 
solution to an artificial problem?

>owner name or other characteristic future unknown meta-RRs will have?

Why tie the RR type code to caching?  If you want a record to not be 
cached, use the TTL field (set it to 0,1,5, whatever).  That's 
another matter, but this came question came to me in another media 
too.  Even in this case, there are a bunch of other ways to stop this 
record from being cached.  (For instance, its RFC2181 trustworthiness 
is low.)