Subject: Re: DNSEXT WGLC: RFC2929bis

From: Måns Nilsson <[email-masked]>
Date: Tue, 01 Aug 2006 17:45:21 +0200

--On onsdag, onsdag 19 jul 2006 14.02.24 -0400 "Ólafur Guðmundsson
/DNSEXT  co-chair" <[email-masked]> wrote:

> 
> This message starts at 3 week last call for this document ending
> on midnight August 10'th 2006 (Reykjavik time).

I have read the draft and support its publication as BCP successor to 2929. 

Regards, 
-- 
Måns Nilsson                     Systems Specialist
+46 70 681 7204   cell                       KTHNOC
+46 8 790 6518  office                  MN1334-RIPE

I'm having an EMOTIONAL OUTBURST!!  But, uh, WHY is there a WAFFLE in
my PAJAMA POCKET??

---

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

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

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.

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

---

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: "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

---

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.

---

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: 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: "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? 

### Thanks,
### Donald

---

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

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

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

>gets a CLASS allocation, you would probably end up having to update

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.

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

---

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

---

From: Sam Weiler <[email-masked]>
Date: Sat, 26 Aug 2006 00:05:31 -0400 (EDT)

Summary: I do NOT support the publication of this document in its
present form.

While I strongly support a templating system for typecodes, I don't
like this one.  First, I'm not sure we need evaulation criteria 3-8 --
why aren't 1 & 2 enough?  Second, I'd rather see a template that can,
in most cases, provide the full spec of the typecode, including the
wire format and presentation format, so that reference to an outside
document is not needed -- I'd like to see the template itself be an
adequate record for most typecode requests.  I'll try to post a sample
template to the list.

It's probably unwise to specify the namedroppers list in Sections
3.1.1 and 3.1.3, since lists occasionally change.  Instead say: "The
DNSSEXT WG mailing list, or another mailing list designated by
the IESG.  Currently, this list is ..."

Seceral sections (3.1.5, 3.2) use "IETF Consensus" as an allocation
metric.  That term is deprecated in 2434bis and should be replaced.

As Thierry Moreau noted: In section 3.1, sentence starting with "Thus
far ...", is missing reference to DLV and TA assignments.  Similarly,
those codepoints need to be excluded from the meta range (and it
should be explicitly called out in the breakdown of the space that
these are normal data types, not "meta types...which it is safe to
simply discard").

Section 3.1.1 item 2: "(b) a Meta TYPE who processing is optional,
i.e., which it is safe to simply discard.".  First, there's the odd
'who'.  Second, is 'discarding' really the right answer when a
recursive resolver gets a meta type query?

-- Sam