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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf