Subject: RE: DNSEXT WGLC: RFC2929bis

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 11 Aug 2006 23:03:04 -0400

Hi Ed,

See below at @@@

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Friday, August 11, 2006 11:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: DNSEXT WGLC: RFC2929bis

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

At 23:21 -0400 8/10/06, Eastlake III Donald-LDE008 wrote:
>Since I posted draft-ietf-dnsext-2929bis-03.txt, two things have 
>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.

@@@ I agree. The last round of changes was primarily adding a bunch of
niggly regulations for the designate expert. Seems to me that an IESG
appointed DNS RRTYPE expert who has available whatever comments people
post on namedroppers for three weeks about an RRTYPE proposal shouldn't
really need a pile of detailed guidelines. But most of those in the WG
who have commented on this seem to be of the other opinion so I put them
in...

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

>(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

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.

@@@ ? Well, yes, the CLASS field is after the labels but label types are
CLASS independent by definition. That means that the wire encoding and
DNS properties (such as "case insensitivity") of labels can't vary by
CLASS. But the user interface properties certainly could. So an
alternative solution to Internationalized Domain Names, which of course
was not adopted, would have been a new CLASS where the current ordinary
"ASCII" labels were always interpreted as UTF-8.

@@@ And, while CLASS can't change the syntax of the TYPE field itself,
it can certainly change the syntax of the RDATA if the TYPE is CLASS
specific.

@@@ One reason to want you own CLASS is to get your own root servers.

>comment, replacement of "RR TYPE" by "RRTYPE" and provision for 
>separate 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.

@@@ Well, first of all I think that after the adoption of 2929bis
(assuming it is adopted), most allocations will be by expert approval
who will work with IANA and most likely get this stuff right. Secondly,
the existing distinction between ranges for data RRTYPEs and meta/Q
RRTYPEs does have some impact on code in that, in the absence of further
knowledge, only data range RRTYPEs should be cached. But I can't see
that the distinction between cross CLASS and CLASS specific ranges I
suggested would have any effect at all on code. It is just intended to
make it possible for someone who does get a CLASS allocation go off and
do their own thing with their own CLASS specific RRTYPEs without having
to worry about clashing with CLASS independent RRTYPEs.

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.

@@@ I don't particularly think that would be a good idea but it isn't
prohibited by the mere order of the fields. If it is too painful in some
implementations to have a 32 bit field with very sparse values, you
could certainly swap around the words/bytes under the covers within
resolver/server without any external sign of this.

@@@ Thanks,
@@@ Donald

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-
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.

--
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: [email-masked]
Date: Sat, 12 Aug 2006 14:37:32 +0000

lets see...  

	) one does not need a new class to have their own root serves. :)
	) i'm with Ed on the fact that this document (and by extention the WG)
	  is obsesed with process.  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?   
	  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.  

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Aug 2006 09:26:24 -0400

Since I'm passing back through the neighborhood after a short trip to 
insanity.  (Believe me, it's usually a very short trip for me.)

>it can certainly change the syntax of the RDATA if the TYPE is CLASS

The core of my point is - but no one has found a use for 
CLASS-dependent RDATA definitions in umpteen years (or ever). 
"Could, would", but "haven't".

That's why I asked "why suddenly the reputed interest in CLASS again?"

Theoretically, oh well, but pragmatically?

>@@@ One reason to want you own CLASS is to get your own root servers.

As Bill says later, you don't need a new CLASS to run your own root.

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Aug 2006 09:10:43 -0700

>The core of my point is - but no one has found a use for CLASS-dependent RDATA definitions in umpteen years (or ever). "Could, would", but "haven't".
>

Just FYI, when I was arguing for draft-hardie-out-rr, I did provide a few
examples (BACNet resources, for example, CDN-specific records, and such).

The proposal did not get traction at the time, and I have no interest in
pushing it again now, but I think the architectural discussion has merit
for the private namespace uses alone.  Split DNS is popular, and it hints
to me that private namespaces could be useful.
				Ted

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 18 Aug 2006 16:27:00 -0400

See below at ### 

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

At 23:03 -0400 8/11/06, Eastlake III Donald-LDE008 wrote:

>@@@ ? Well, yes, the CLASS field is after the labels but label types 
>are CLASS independent by definition. That means that the wire encoding 
>and DNS properties (such as "case insensitivity") of labels can't vary 
>by CLASS. But the user interface properties certainly could. So an 

>it can certainly change the syntax of the RDATA if the TYPE is CLASS 

The core of my point is - but no one has found a use for CLASS-dependent
RDATA definitions in umpteen years (or ever). 
"Could, would", but "haven't".

###  I don't know if any of the existing CLASS dependent RRTYPEs have
different real uses in the HS or CH CLASSes but, if you assume that IN
is the only CLASS that will ever matter or be used in a significant
portion of the networks in the world, then there is no difference
between CLASS specific RRTYPEs and cross CLASS RRTYPEs. So it seems like
your statement that "no one has found a use for CLASS-dependent RDATA
definitions" mostly reduces to no one deciding to use a CLASS other than
IN. Once they have decided to use IN, it immediately closes off all
possibility of using a different meaning for a CLASS dependent RRTYPE so
there is no reason for them to even think about it.

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

### If you are asking why I was thinking about CLASS, working of 2929bis
automatically forces me to think about all these various code points,
their interactions and their allocations. It didn't make me think very
hard about CLASS/RRTYPE interactions because I missed this issue until
the WGLC for 2929bis. In fact, likely I had thought of this before and
just put it in at an earlier version of the draft, no one would care
very much and we wouldn't be having this conversation and it would just
go through and be part of the new BCP.

### 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
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.

### And, as I answered him: "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." 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.

### Thanks,
### Donald

---

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

>to me that private namespaces could be useful.

Split DNS is an essential part of DNS operations.  Private name 
spaces are also essential.  But CLASS is not the tool to use.

One parallel to CLASS is IPv6's old scoped addressing concept, site 
local for instance.  That has died because the sort of applications 
that would have used it are too easily confused by also having 
globally unique addresses.  (Would an application use the site local 
or globally unique address in a certain instance?)

When would an application look up a name and type with QCLASS 
"local"?  If this was done in parallel with an "IN" CLASS lookup, 
aren't we guaranteeing a wasted UDP transaction?  If in serial, 50% 
chance of wasting some time?  If you choose the CLASS by looking at 
the name, then why burn a CLASS type?  If you make CLASS=f(NAME), 
then we've lost the "degree of freedom" CLASS was supposed to give.

A more common set up for private name spaces is to have the root of 
the private name space sitting on servers that have a filtering fire 
wall between them and the Internet.  Internally, a resolver can go to 
the ICANN root, TLDs, down and then to the local servers (assuming 
there's nothing in cache, etc., etc.).  Outsiders will also see the 
delegations, but hit a lame server when they try to "get into the 
fire wall."  The thought being "outsiders ought to never try to come 
in, so this is acceptable breakage."  CLASS isn't used to separate 
the servers, network layer security is.

DNS' CLASS just doesn't make sense anymore.