Subject: RE: DNSEXT WGLC: RFC2929bis

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. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Wednesday, August 16, 2006 11:14 AM
> To: Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: DNSEXT WGLC: RFC2929bis
> 
> At 14:08 -0400 8/12/06, Eastlake III Donald-LDE008 wrote:
> 
> >@@@ 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.
> 
> 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.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-
> 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/>
> 
> 

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

> 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).
> 
>  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.
> 
> --
> [email-masked] with the word 'unsubscribe' in a 
> single line as the message text body.