Gentlemen,
Re: §4.2 of your IAB Draft draft-iab-dns-applications-00:
(http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt)
Send-N is not only intended for open number plans, it's intended for use in
_any_ plan with variable length telephone numbers. It came out of the proposed
specifications for the UK local number portability database, where E.164
numbers vary from 8 to 12 digits in length.
A typical application for Send-N might be where an analogue phone is attached
to a CP-managed SIP ATA - this will be a common setup in "Next Generation
Networks".
It is a solution to the problem of gatewaying between the 100s of millions of
dumb handsets that use overlapped dialling[*] and the SIP world where
overlapped dialling is not currently feasible. As an analogue phone has no
"dial" button the ATA must listen for DTMF digits, and somehow figure out for
itself when the user has finished dialling before initiating the SIP call over
the ATA's SIP trunk.
A common (but unreliable) method is to use inter-digit timeouts, but the end
user experience is poor - it might take the ATA a few seconds to start the SIP
session after the last digit is dialled. Assuming that the ATA doesn't do ENUM
dips itself, the existing alternative would be for the ATA to establish a brand
new SIP session after each digit is dialled, receiving a "484 Address
Incomplete" error from the CP switch until the number is complete.
With Send-N metadata available, the definition of the SIP "484 Address
Incomplete" could be extended to return the Send-N data so that an ATA can
benefit from this information and omit unnecessary SIP session establishments.
Regarding this sentence:
"Maintaining that synchronization, however, requires that the
DNS have semi-real time updates that may conflict with scale
and caching mechanisms."
As Jon pointed out during the ENUM session at Maastricht there is indeed a need
to synchronise the metadata with the underlying data. However number plans are
not generally prone to sudden unexpected changes. In any event with Send-N the
only identified synchronisation issue is when a Send-N record indicates that
_more_ digits are required than is actually the case. Since it is very rare
(if not unheard of) for number blocks to get smaller I don't consider this a
significant risk.
The assertion therefore appears to be unjustified.
And finally, regarding:
"It is unclear why this data is better maintained by the DNS
than in an unrelated application protocol."
If a device is performing an ENUM dip hoping to find a contactable SIP URI, it
is simply most efficient for the ENUM response to directly include the Send-N
metadata when needed rather than have separate queries using a different
network protocol. Also, the hierarchical and distributed nature of the DNS
protocol makes it an _ideal_ structural fit for this meta data.
I believe the onus should be on your draft to explicitly identify valid
technical reasons why the DNS protocol should _not_ be used, rather than make
vague hand-waving assertions which appear to have little or no justification.
kind regards,
Ray
[*] the draft misdescribes overlapped dialling - it's the practise of sending
digits to the network as they're received rather than "en bloc" at the end of
dialling. It's what analogue phones do, and is completely separate from "open
number plans".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf