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

At 18:08 +0200 6/30/08, Peter Koch wrote:

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

I'm responding to Peter's message to amplify at least to very good 
points he made.  This is one of them.

When I read the draft, I was first shocked at the choice of a 
relative number in the record.

My mind shot back in time to the debates over the IPv6 records for 
addresses, namely the AAAA record (and PTR for reverse) and the A6 
record (with something called bit labels for the reverse).  The 
former was the already defined, static absolute approach, the latter 
an up and coming relative approach, all the rage at the time (2001).

The benefits of A6/bit labels were that it was helpful in network 
renumbering, that is, if the (IPv6 network) prefix changed the local 
part could remain the same. The change would have very little impact 
on the provisioned data in the DNS.

The drawbacks became evident when the experts tried to explain how 
this worked on the chalkboard.  I never saw anyone walk through an 
entire, non-trivial example without a serious error.  That is, it was 
confusing for even an expert (much less a field engineer debugging a 
live system).  Secondly, with some carefully crafted entries, it was 
possible to tie up the resolution process in a nearly endless cycle 
of queries and assemblies of addresses.

I should point out that some of the drawbacks were unique to the 
A6/bit labels.  This is because it was the DNS as client in the 
lookup process.  With the send-n  use case, the DNS is only on the 
server side and wouldn't suffer.  Still, to this day relative offsets 
carry red flags as there is a potential for errors to pop up in the 
ENUM clients.

This is why my knee-jerk reaction is to suggest that absolute numbers 
be used.  A little pain in the provisioning side will save a lot of 
suffering on the resolution side.  DNS's great strength is the 
resolution side, don't hamper it!

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

This isn't a DNS topic (referring to Peter's title as DNSOP chair as 
representative of one of his fields of expertise), his words echo my 
thoughts as I read the draft.  I do know that there are times I half 
dial a number and then have to squint again at a piece of paper, but 
it is usually apparent when the dialing is over.  Further, telephone 
dialing is so slow now, I wouldn't know if there was a longer delay 
"just to make sure" I was done dialing.

>Apologies.  NAPTR is becoming the TXT RR for enum; everything can be put

Back to the DNS side of the house, this is another opinion of Peter's 
I will second.  If you want to put a dialing plan in the DNS, just 
use TXT records and store it somewhere else!  The NAPTR has two 
outcomes - rewriting the URI you are trying to resolve or redirecting 
your DNS lookup.  Using it to convey data about the data model, well, 
it may be possible, but not in the scope of the NAPTR mission.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.