Re: a new RRype instead of send-n NAPTRs

On Tue, Jul 22, 2008 at 08:22:03PM +0100, Jim Reid wrote:

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

well, this is not only about delegations and zone cuts, but about general
properties of the namespace.  And even though we have a hierarchy, the
DNS follows the principle that any information is published in place,
not inherited from "above", because such an inheritance doesn't exist.
For example, we have _lots of_ domains under DE which are maintained within
the DE zone.  Still no data at the DE level should apply to these domains
any more or less than it applies to a delegated domain -- zero in both cases.

Now, that's the general DNS rule.  However, there are parts of the DNS
namespace that are mappings of other name- or numberspaces, like e164.arpa.
The question of hierarchy, inheritance and the like is influenced by
the properties of the mapped name- or number space, not the DNS.
Therefore I doubt anything "generic" at the DNS level could or should help.

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

Except that it might not be eligible for the 2929bis process if it tries to
be "DNS generic" and it wouldn't have the appeal of being automatically
piggy backed onto the DNS response, like any NAPTR "re-use" would.

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

Mobile devices have been mentioned as where latency matters, but then
I wonder why overlap dialling would appear with those devices in the
first place, since we're usually used to press the "green" button on
handhelds anyway.
The figures I've seen so far re: query volume have neither been frightening
nor convincing, so I'd like to re-issue my plea to first agree on the
size of the problem before designing or even standardizing a solution.

What I'd also like to learn during the Dublin discussion is whether "send-n"
is envisioned for private I-ENUM only or also for other applications and
whether the envisioned scenario (in case of private I-ENUM) would or
would not involve a "normal" DNS server and resolver infrastructure, including
delegations and caching, that is.

-Peter