> understood. Since that is an optimization for a provisioning issue of
> - to me - unclear frequency of occurence, would much be lost with using
> the absolute value only?
Personally I'm not sure. Clive thinks relative is useful.
> Also, since you mention renumbering, is this mostly aimed at PBX
> installations?
No, at carrier level switches.
> Would your model envision those number ranges to be delegated out of the
> I-ENUM tree?
It's theoretically possible, but not expected.
> From the DDDS perspective partial numbers would just not resolve.
> "Send-N" piggybacks info on top of "does not resolve" and starts a new
> DDDS resolution cycle. That's not too sound IMHO.
I've been trying to break apart the confusion between overlapped dialling
and Send-N. It's the former that starts a new DDDS resolution cycle. The
latter shortens the number of times it might happen.
> "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?
> Inter-digit timeouts, as far as I understand, would bite the dialing
customer
> at the end of their dialing process because only after the timer's
> expiration would the full number be submitted to the ENUM lookup
mechanism.
> But since the human can't dial at light speed - where's the gain in
terms
> of latency over just querying after each digit pressed?
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"?
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.
> Apologies. NAPTR is becoming the TXT RR for enum; everything can be put
> in there so conveniently, especially using "data" type URIs. That's not
> what NAPTR was designed for. And the fact that NAPTR is asked for and
thus
> this metadata can be sent by way of NAPTR appears more a bug than a
feature
> to me.
Ah, yes. I was advised that the "pstndata" Enumservice and URI scheme had
been devised specifically to mitigate the way that people were making up
arbitrary "data:," URI formats or otherwise sticking stuff in TXT records.
Hence why this draft draws on Richard's stuff in the CNAM draft.
> I'm sorry, but your proposal is only one in a line of "tiny
optimizations"
> needed for the "perfect fit" of "ENUM technology", or DNS in general,
> for the LUF/LRF problem. That could be perceived as a big "wrong way"
> sign on that road.
For the UK NGN standards, this is about as far as DNS goes. The LUF/LRF
is still going to be done with bilateral interconnect agreements.
Ray
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.