Re: draft-iab-dns-applications - clarification re: Send-N


While I understand that there are a number of interesting questions about the 
DNS in play in the industry today, the subject of the iab-dns-applications 
draft is the dividing line between application functionality and the domain 
name system. Its target audience is the application protocol designer, really - 
an engineer who sees a gap in their application architecture and asks "can this 
hole be plugged by extending the DNS?" Its underlying aim is to lay down a few 
architectural principles to help engineers in that situation to find solutions 
that work well, within or outside of the DNS architecture. It is not specific 
to ENUM, though obviously the discussions surrounding the E2MD BoF informed 
some of these design choices.

The six questions you pose below all give rise to practical, operational 
concerns with varying degrees of urgency, but I'm not sure they cast their 
problems exactly in the scope of the iab-dns-applications draft. For the sixth 
question, for example,  the draft is indeed at a high level concerned that 
answers may vary depending on who is asking, but it examines the more narrow 
question of whether the DNS should be extended to convey information 
attributing to a DNS query some particular "source," and what the implications 
of such an extension would be. Those implications don't stop at recursion and 
caching - more broadly, they involve the sort of trust relationship we imagine 
might exist between resolvers and servers. That is one thing when, say, Google 
serves a customized national home page based on the source IP address of a 
browser, and another thing when the DNS tries to serve potentially sensitive 
information only to authenticated parties. When we have an application with 
that latter requirement, we then face the "dividing line" question - should we 
try to extend the DNS to implement this authentication, and an architecture 
that will support it, or should we defer this requirement to a higher-layer 
application? Do higher-layer applications have capabilities, trust-relationship 
assumptions and architectures more congeal to the resolution of these 
requirements? The guidance in the iab-dns-applications draft is intended to 
address that sort of question.

Does that make sense? Again, this is not to suggest your questions are 
unimportant, but just that we're aiming for a slightly different mark here. 
Your feedback is however very useful in trying to better explain and refine the 
scope of the document, as well as the individual considerations it details.

Thanks,

Jon Peterson
NeuStar, Inc.

On 10/24/10 10:42 AM, "Lawrence Conroy" 
<lconroy(_at_)insensate(_dot_)co(_dot_)uk> wrote:

Hi Jon, Richard, Ray, folks,
 I've been looking though the DNS-applications draft, and I'm unsure on its 
underlying aim.

We've already discussed the potential for "ENUM-Ops" style work to put 
clarifications
on how ENUM and ENUM-like systems should be used. The fact that there has been 
little
on the appropriate mailing lists on that topic doesn't mean that task has been 
overlooked
(there have been other distractions :).

There is certainly a good reason to issue DNS application guidance now,
 and some of the features of DNS may not be what applications expect.
... BUT ...

Q: Are you arguing that some applications will make cacheing less effective and 
that this will be a problem?

Q: Are you arguing that over-use of DNS is generally a problem (e.g. due to 
lack of prioritisation of query processing)?

Q: Are you arguing that volume and size of data will unbalance intermediary 
cacheing servers and undermine their effectiveness/"hit rate"?

Q: Are you arguing that the size of RRSets will cause upstream servers to face 
difficult decisions in populating the answer and authority section of DNS 
responses?

Q: Are you arguing that the size of RRSets will force difficult decisions on 
upstream servers populating the additional section of DNS responses?

Q: Are you concerned that answers may vary depending on who's asking, and that 
this may damage the effectiveness of cacheing and/or the DNS infrastructure?

-- consider the Yahoo/Google (edns-client-subnet) proposals for 
Internet-answering resolvers to support CDNs better (dwarfing use in 
private/internal telecommunications data networks)
-- consider the Google opt-in scheme for IPv6 networks, giving different 
answers depending on whether or not the network is "known to work with" IPv6 
answers "correctly"+?
  +: see <http://www.google.com/intl/en/ipv6/> for requirements

----

I believe that there ARE underlying issues with application use of DNS, and so 
guidance is definitely needed.
I'm however not convinced that the current draft chooses the best exemplars of 
these issues.

*  Frankly, the dynamism of the telecommunications data set is low (as you all 
know).
 The queries are susceptible to cacheing (or the systems WILL be designed to 
cope, where that is not a valid assumption).
(ASSUMING OF COURSE THAT "in-use" STATUS IS NOT TO BE REFLECTED IN DNS. No-one 
has ever suggested to me that fine grained presence data should be in DNS, yet 
that seems to be the only valid coherency concern).

*  Telecommunications data is under the control of those provisioning the data 
into DNS;
 For Telecommunication data provisioning, synchronisation seems to be an issue 
only of appropriate TTLs.
 Dynamic update DNS services already face this issue and deal with it.
 - "Applications should consider data dynamism and DNS synchronisation" is an 
eminently valid guideline, but ISPs' dynamic address assignment and third party 
Dynamic DNS services would seem a more appropriate example.

*  The size of ENUM answers is subject to the same restrictions as other users 
of DNS.
 Performance may will be helped by support for EDNS, but this is needed for all 
users of DNSSEC.
The approach used already (for example) for gmail.com's MX records has NOT been 
proposed for public ENUM use.
It's unclear if the concern over size raised in the DNS-applications draft will 
be misinterpreted as advice for people to apply such "techniques" to ENUM 
answers provided on the Internet.

*  The number of queries in a valid chain is limited; there simply aren't that 
many queries that need to be made for communications-related data.
 "Communications" may involve more than just application server addresses, but 
it IS limited.
 The new version of the ENUM standard has recommended "loop control" (see 
draft-ietf-enum-3761bis-09.txt, ends of sections 5.1 and 5.2),
 and has a recommended mechanism for "leakage control" (ibid, 3.4.3.1).
 Thus the concerns over long chains and leakage raised in the IAB-applications 
draft seem outdated, at least as far as ENUM is concerned.

Maybe it's just me, but I want a good guidelines document (so we don't HAVE to 
work so hard for an ENUM-specific set :),
but I'd like the guidance to spell out answers to the six questions above, or 
cover them more clearly.
At present I'm just guessing.

all the best,
  Lawrence


On 21 Oct 2010, at 05:11, Peterson, Jon wrote:

As tempting as it is to join the cries of "imminent death of the PSTN 
predicted," I wanted to drill down at some length into Ray's question on 
send-n and some of Rich's comments.

Regarding send-n, the argument made by the dns-applications draft today is 
that the synchronization required to coordinate different levels in the DNS 
tree with the state of resources in the telephone network creates a 
fundamental brittleness in this architecture. It is presented in those terms 
to try to abstract out the architecture principle rather than staying 
strictly within the particulars of the send-n proposal, since the guidance on 
that subject did seem generalizable to proposals other than send-n. It is not 
intended to be a sole and decisive refutation of the send-n proposal. 
Certainly we don't want to "just say no" to the overlap dialing problem 
space, but it does hope to encourage thinking about alternate ways of 
satisfying the send-n requirements that don't suffer from this problem. When 
importing this overlap dialing from the PSTN to the Internet, we have a 
number of architectural alternatives we can explore to mirror this 
functionality which may or may not map directly onto the processes of the 
PSTN. It is, as the dns-applications draft says, unclear why DNS is 
necessarily the best of them.

I agree that the distributed and hierarchical nature of the DNS makes it 
potentially applicable to overlap dialing,  since it does allow you to 
traverse a tree which can ultimately delegate to the entity that sets the 
length of a telephone number. What you don't mention here, however, is that 
there are a number of fundamentally different approaches to overlap dialing.  
Many native VoIP handsets, much like mobile phones, do not provide a "dial 
tone" experience but instead wait for a user to press a "send" or "call" 
button before attempting to reach a number. For those entities that do get 
numbers piecemeal (like ATAs, or VoIP gateways receiving a possibly 
incomplete IAM from the PSTN), I understand some implementations have a 
collection timer that waits until the stream of digits has concluded before 
attempting to reach a number.

However, if we assume that the delay incurred by that timer is intolerable, 
we're then left with the problem that these ATA-like VoIP endpoint won't know 
that an address is complete until they've tried to place a call or sent an 
ENUM query that may fail. An ATA that supports ENUM might therefore make 
several queries, some which will be unsuccessful, before it collects all the 
digits and makes a query that returns a useful response. The motivation of 
send-n is to reduce the number of those ENUM queries. It proposes an 
optimization, and one that is scoped to a particular segment of the PSTN that 
supports overlap dialing, and furthermore to those use cases like dial-tone 
simulation or certain gatewaying architectures where timers or "send" buttons 
don't address the problems. In those cases, it prevents DNS servers from 
enduring the load of some of these futile queries by piggybacking onto 
preliminary ENUM responses a minimum number or digits that must be collected 
before launching a query. As an optimization, that reduction in queries has a 
certain architectural value, but we do need to assess that value objectively 
- I'd say it is a bit much to construe skipping those queries in those cases 
as an "essential function in the transition from analog POTS to SIP based 
communication." Supporting overlap is essential - optimization is nice.

If we grant that this problem of futile queries is onerous enough to require 
optimization, the question then becomes whether the optimal way for one of 
these endpoints to learn the minimum number of digits is by asking the DNS a 
la ENUM, in real-time as the endpoint is setting up a call. Is there a way 
endpoints could acquire a picture of the numbering plan not in real-time 
during call set-up, but through some prior procedure like periodically 
querying for (or subscribing to) a picture of the dialing plan when the 
endpoint is idle; i.e. If it is possible to reduce even further the number of 
queries that need to be made in real-time while an endpoint is setting up a 
call? What about endpoints that don't use ENUM - would they also care about 
that minimum number of digits (say, when an endpoint just dumps a call to a 
PSTN gateway for want of ENUM), and if so would it make sense to make this 
information available outside of ENUM? And finally, is the stated 
functionality really a good fit for the DNS? How do entities that have been 
delegated numbers get the permission to provision records (for "partial" 
numbers) outside of their zone of authority? Do the records require 
synthesis? What happens when you try to resolve a partial number that might 
in fact be a prefix for blocks of numbers in distinct administrative domains? 
Are there any analogous cases like this for ordinary domain name resolution 
(maybe Google autocomplete will be the overlap dialing of the future...)?

I wouldn't say that the message of the dns-applications draft is "do not 
charter E2MD," in so far as it does not reject the problem space. It does try 
to capture arguments that had previously only been presented anecdotally, and 
it moreover intends in the future to capture the ongoing discussions we've 
now begun about these subjects. I do however maintain that the previous E2MD 
chater is a collection of problems that have different underlying 
requirements, and that bringing them under a common architectural umbrella 
may obscure their individual problem spaces rather than illuminating them. 
Also, the insistence of the charter on DNS-based solutions, as opposed to 
solutions that might not involve the DNS, seemed unnecessarily confining, for 
send-n and other mechanisms under consideration.

Jon Peterson
NeuStar, Inc.

On 10/20/10 3:25 PM, "Richard Shockey" <richard(_at_)shockey(_dot_)us> wrote:



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.



RS> Precisely, What is unclear is why the IETF and the IAB is suddenly
trying to block a perfectly legitimate extension of RFC 3761 that is in
various forms of global deployment, proven to work, scale and more
importantly provides a valuable and essential function in the transition
from analog POTS to SIP based communication.

Just saying no is not a solution to the real issues of number translation in
carrier networks.

Ok a lot of people hate phone numbers including, it seems, 50% of RAI
directorate but they are not going away anytime soon.

So just say it .. is this the message? Don't even try to charter E2MD?


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf