a new RRype instead of send-n NAPTRs

Apologies for using a meaningful Subject: header. Well someone had to  
make a start.....

On 20 Jul 2008, at 20:43, Jay Daley wrote:

> Duane wrote on 20/07/2008 05:19:20:
>
>> If you aren't going to pre-populate a DNS database (like BIND) then
>> where is the issue with sticking it under some other RR type?
>
> 1.  Because we only need it for ENUM.

No, it's needed for a behind-closed-doors version of 4.4.e164.arpa.

> 2.  Because the hierarchy of ownership of labels for ENUM is  
> completely
> different from the hierarchy for ordinary DNS

Rubbish. The DNS has never, ever cared about "ownership of labels"  
whatever that means. A client does a lookup and gets a response. It  
doesn't have the slightest interest in who "owns" the label or  
operates the name servers for it.

> and in ordinary DNS it is
> not acceptable for the owner of one label to make authoritative  
> statements
> about a lower label under different ownership.

Aha! I suppose you mean delegation points and zone cuts. Well what you  
say is true up to a point: though our DNSSEC friends have done a good  
job of demolishing that. DS records, anyone?

Even so, your point Jay is a diversion. IIUC, there won't be  
delegations in this behind-closed-doors version of 4.4.e164.arpa. This  
list has been told about a monolithic name space, database driven DNS  
records and even responses being generated on the fly. This doesn't  
look anything like a conventional delegation model where longer labels  
are handed out to distinct "owners". Or am I missing something?

> Not to mention the fact that this is the wrong place to discuss this -
> DNSEXT is the place for a new general RR.

Indeed. This is why I privately suggested to Ray that he replace send- 
n with a new RRtype template that should sail through the 2929-bis  
process.

Aside from all the heat that's being generated here, I think send-n is  
in trouble because it does not define a URI. I'm still far from  
convinced about the alleged benefits of saving the odd DNS lookup: the  
latency is one valid point, but some extra queries, so what? The  
resolving entities will presumably acquire a rich cache very quickly,