Re: Send-N draft: draft-bellis-enum-send-n-02 published

Ray,

> > "Send-N" stuffs lots of metadata in the tree that I think doesn't
> > belong there.
>
> As a DNS guy, do you see any mileage in Eleanor McHugh's suggestion of an
> RR that could represent tree-depth information in *any* DNS tree?

You mean this [quoting Eleanor McHugh]:
>> You've identified an interesting problem: how to validate the depth/
>> shape of namespace tree branches allowed given an intermediary point
>> on that tree. A general case solution using a new RR type could be
>> useful in places other than just ENUM, and if that's the case your
>> send-n proposal will either lead to the proliferation of copycat
>> solutions in other hierarchies or else be an evolutionary dead-end
>> when an RR does get defined. Therefore you have nothing to lose by
>> proposing an appropriate RR in the first place.

Well, I guess, I can say I share the academic interest, but I'm not sure
this is in any way better than "send-n" except its generality. One could
define a QTYPE that would return the number of empty non terminals at
or below a node in the DNS tree.  Still I don't agree with the need.

> Yes, for the user it's the final digit time-out.  When should the switch
> decide "enough is enough, it's time to try an ENUM lookup"?

Depending on the numbering plan determined by country prefix, it might be
sufficient to suppress the first n queries, where n is, say, two more than
the length of the area code being dialled. That would mean the client was
able to identify the are code.  But the ENUM lookups don't have to be blocking,
so why not let the client send an ENUM query after every digit (see above
for prefix/area code considerations)?

> For the server it's a potential 5-fold reduction in the number of queries.
>  If your switches are doing this lookup for every telephone call that's a
> *lot* of queries saved.

In the best case, maybe, but you need the cooperation of the clients and you
add a lot of complexity to the ENUM tree.  I've still not seen a convincing
argument that this query optimization is solving a real load problem.
Apart from that, there's also lots of optimization opportunity in the client
if you just let the client remember what a "full number" was; I've been
told this is already done.

-Peter