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

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Oct 2010 10:27:32 +0000

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".

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Oct 2010 20:04:42 +0900

Ray Bellis wrote:

> Send-N is not only intended for open number plans, it's intended
> for use in _any_ plan with variable length telephone numbers.

Such a mechanism simply does not work when:

   <draft-iab-dns-applications-00>
   In these
   plans, a telephone switch ordinarily cannot anticipate when a dialed
   number is complete, as only the terminating customer premise
   equipment (typically a private branch exchange) knows how long a
   telephone number needs to be.

where even telephone switches (thus, telephone operators) do not have
any knowledge on how many numbers should be dialed.

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

If the number portability database operated by telephone operators
can eve exist, it is impossible that CPEs operated by subscribers
determine the length of telephone numbers.

							Masataka Ohta

---

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Oct 2010 11:15:06 +0000

> any knowledge on how many numbers should be dialed.

It is for this reason that Send-N specifies the _minimum_ number of required digits, not the exact number.

Ray

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Oct 2010 21:21:12 +0900

> required digits, not the exact number.

It contradicts with the following description of the draft:

   With
   this information, the application is not required to query the DNS
   every time a new digit is dialed, but can wait to collect sufficient
   digits to receive a response.

That is, the application can wait to collect sufficient digits to
know the _minimum_ number means that the application MUST know
the minimum number of digit to make such query, even though E.164
structure often changes.

Worse, even if the application knows the _minimum_ number, the
application MUST make DNS querys for every digit beyond the
_minimum_ number, which means negligibly small number of queries
could be saved.

						Masataka Ohta

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Oct 2010 15:25:05 -0400

And finally, regarding:

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?

---

From: bill manning <[email-masked]>
Date: Wed, 20 Oct 2010 12:43:04 -0700

while I agree that the hierarchical and distributed nature of the DNS is
a scintillating, shimmering attractant, it is wise to be aware of the baseline
assumption in your arguement, e.g. that a client will -ALWAYS- ask an authoritative
source... 

The DNS is so designed that caching is a huge component of the scalability of
the DNS... and its greatest hinderance for such ideas as are laid out in the ENUM
dip lookup.    You can't be assured that the data is timely.  This is a strong reason 
to consider that the DNS is _NOT_ the droid you are looking for,  in spite of its other
attractive qualities.

just my 0.02 lira.

--bill

On 20October2010Wednesday, at 12:25, Richard Shockey wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2010 13:18:03 -0700

>to consider that the DNS is _NOT_ the droid you are looking for,  in spite of its other

This line of reasoning is getting old. DNS records have TTLs that are established at the same time, and in the same interface, as the data itself. Caching based on TTLs is trivial to do, and devices that do it wrong usually don't do it at all, which affects long-lived TTLs just as badly.

If you want to argue "TTL=5 considered harmful", that's fine, but for the kind of data that is being discussed here (someone's phone number, not Google's IP address), the operational difference between TTL=3600 and TTL=5 is lost in the noise. And it's not like the alternative you are hoping they use, HTTP, is any different with respect to caching, systems that ignore the TTLs, and so on.

--Paul Hoffman, Director
--VPN Consortium

---

From: bill manning <[email-masked]>
Date: Wed, 20 Oct 2010 13:36:08 -0700

Paul, if you posit that TTL manipulation is the sole problem w/ caching, then you
might be right.  My experiences with cache manipulation suggest there are many 
other problems with the existing caching design as used by the DNS.  Your 
experiences may be different and the assumptions in the draft may include caching
behaviours.  Based on Richards email, it didn't seem so.

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Oct 2010 13:38:08 -0700

On Oct 20, 2010, at 1:36 PM, bill manning wrote:
> My experiences with cache manipulation suggest there are many 
> other problems with the existing caching design as used by the DNS.  

Such as?

Thanks,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Oct 2010 16:42:10 -0400

I don't much see the issue here.

Looking at my AT&T records, I have made about 1000 iphone calls in the past
year. Of those less than 50 are to numbers not in my contacts and I probably
dialed half of those using Safari.

Telephone numbers are not going away, but telephone dialing is already a
necessary legacy thing more than a current requirement.

At this point I don't think that there are any telephone numbers I dial from
memory.

I think that the underlying problem here is that the crappy POTS handsets on
sale today do not interface to Internet telephony systems well.

This whole problem would go away if Cisco and the other makers of VOIP
bridges worked out that the real market requirement here is for a box that
plugs into an ethernet port and connects to DECT6.0 telephones rather than a
box that plugs into an ethernet port and has telephone wires sticking out
the back.

That way the VOIP system knows how long the telephone number from the phone
book entry. Your basic problem here is that you are losing this information
by converting all your data to the obsolete POTS wire format and back.

Anyone who wants to do that should further realize that what they need to do
is to allow for multiple boxes on the same VOIP connection in a secure
fashion. DECT6.0 does not have the range to cover some houses and for some
reason the pinheads that designed it seem to think that 6 phones is enough
for one house.

On Wed, Oct 20, 2010 at 4:18 PM, Paul Hoffman <[email-masked]> wrote:

> This line of reasoning is getting old. DNS records have TTLs that are
> established at the same time, and in the same interface, as the data itself.
> Caching based on TTLs is trivial to do, and devices that do it wrong usually
> don't do it at all, which affects long-lived TTLs just as badly.
>
> If you want to argue "TTL=5 considered harmful", that's fine, but for the
> kind of data that is being discussed here (someone's phone number, not
> Google's IP address), the operational difference between TTL=3600 and TTL=5
> is lost in the noise. And it's not like the alternative you are hoping they
> use, HTTP, is any different with respect to caching, systems that ignore the
> TTLs, and so on.
>
> --Paul Hoffman, Director
> --VPN Consortium

-- 
Website: http://hallambaker.com/

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Oct 2010 16:47:00 -0400

Well Bill with due respect, the data that most of us would like to use for
this class of application is very static and its sources are very
authoritative. That which is somewhat volatile is easy to sync such as Local
Number Portability data or line status. There is a staggering amount of data
in the field that Infrastructure oriented ENUM works and works well in the
field. Speed and scale were the keys and the desire NOT to have another
protocol stack in mission critical network elements such as the CSCF or SBC
at the edge of the SIP/IMS networks.

But the larger issue is this. When the ENUM WG was rechartered it was
explicit that this class of application was in scope. Now for some
inexplicable reason its out of scope. I want to know why.

"3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed
by E.164 numbers, for example PSTN call routing and signaling data."

As a practical matter the horse has left the barn, mated, now has several
foals. 

This document is a terrible attempt at an ex post facto architectural
decision that is significantly damaging to those of us who want to make
things in SIP work better. As a practical matter I want to know are all of
these proposals for PSTN metadata, trunk group, SPID, source URI etc are now
out of scope for IETF standardization. Even as private deployments?  If so
than the IESG and the IAB should say so explicitly now and not waste our
time in Prague on a BOF that will never be chartered.

I personally find section 5.1 unusually amusing as if now the IAB wants to
say split-DNS "should be considered harmful". Leakage in to the public DNS
.. geez really. Like what where are the examples of the harm? So who put
ringtones in the DNS :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of bill
manning
Sent: Wednesday, October 20, 2010 3:43 PM
To: Richard Shockey
Cc: 'Ray Bellis'; [email-masked]; [email-masked]
Subject: Re: draft-iab-dns-applications - clarification re: Send-N

while I agree that the hierarchical and distributed nature of the DNS is
a scintillating, shimmering attractant, it is wise to be aware of the
baseline
assumption in your arguement, e.g. that a client will -ALWAYS- ask an
authoritative
source... 

The DNS is so designed that caching is a huge component of the scalability
of
the DNS... and its greatest hinderance for such ideas as are laid out in the
ENUM
dip lookup.    You can't be assured that the data is timely.  This is a
strong reason 
to consider that the DNS is _NOT_ the droid you are looking for,  in spite
of its other
attractive qualities.

just my 0.02 lira.

--bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Oct 2010 16:49:52 -0400

I can see how the IP address on which the customer is getting service might
change more quickly than you might want for telephony.

But that would seem to me to be something that the application layer is
going to have to take account of. DNS may not be the ultimate discovery
scheme you want, but it is going to have to be a part of the scheme you use.

Also, the people who hook their systems up to these infrastructures know
that they are doing telephony. So presumably they are not just blindly
connecting up to the local broadband providers DNS on the offchance it might
be run appropriately for their needs.

So while people do screw up DNS service at certain sites, that does not
necessarily need to be a blocking factor here.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Oct 2010 16:51:26 -0400

So what is your point ..you don't use phone numbers so the rest of the
planet shouldn't? 

From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2010 4:42 PM
To: Paul Hoffman
Cc: bill manning; Richard Shockey; Ray Bellis;
[email-masked]; [email-masked]
Subject: Re: draft-iab-dns-applications - clarification re: Send-N

---

From: bill manning <[email-masked]>
Date: Wed, 20 Oct 2010 13:58:17 -0700

> at the edge of the SIP/IMS networks.

	right... but only rarely in the DNS world do edge nodes actually go hit
	the authoritative sources.  much/most of the time they hit a cache, often 
	one run by a random third party.   Now if one presumes DNSSEC signed
	data, then most of my concerns evaporate.

> inexplicable reason its out of scope. I want to know why.

	that is a very good question.  the concerns wrt data "bloat" are much less
	of an issue now than they might have been last century.

> time in Prague on a BOF that will never be chartered.

	well... if its done faster/better outside the IETF by an industry group...

> .. geez really. Like what where are the examples of the harm? So who put

	oh... leakage into the public DNS means that the root nameservers have to be
	over-provisioned by a couple orders of magnitude to deal with the crap that should
	be in private space but leaked out and can't be resolved.    Thats a real cost and
	its handwaived over by most folks.  "Someone else will deal w/ it."

	ringtones?  can't say for sure.  I know there calculators, games, books, and 
	SSH  & HTTP sessions running through the DNS.  Ringtones?  Piece of Cake.

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Oct 2010 14:06:21 -0700

Bill,

On Oct 20, 2010, at 1:58 PM, bill manning wrote:
> 	one run by a random third party.  

I would truly love to see the data you have that backs this up.  Pointers?  (Note that this is not rhetorical -- I'm doing some work right now in which this info would be quite helpful).

> 	be in private space but leaked out and can't be resolved.    

I thought the (vast) over-provisioning of the root servers was to cope with DDoS attacks.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Oct 2010 17:15:27 -0400

I use telephone numbers, but I don't use a dial pad to dial.

And I strongly suspect that my mode of use is the norm.

Since we are talking about an optimization here, as opposed to a functional
capability, I think it rather more important to look at the real
requirements and optimize for that case rather than optimize for a mode of
use that is rapidly becoming obsolete.

On Wed, Oct 20, 2010 at 4:51 PM, Richard Shockey <[email-masked]> wrote:

>  So what is your point ..you don’t use phone numbers so the rest of the
> planet shouldn’t?
>
>
>
> *From:* Phillip Hallam-Baker [mailto:[email-masked]]
> *Sent:* Wednesday, October 20, 2010 4:42 PM
> *To:* Paul Hoffman
> *Cc:* bill manning; Richard Shockey; Ray Bellis;
> *Subject:* Re: draft-iab-dns-applications - clarification re: Send-N
>
>
>
> At this point I don't think that there are any telephone numbers I dial
> from memory.
>
>
>
> I think that the underlying problem here is that the crappy POTS handsets
> on sale today do not interface to Internet telephony systems well.
>
>
>
> Anyone who wants to do that should further realize that what they need to
> do is to allow for multiple boxes on the same VOIP connection in a secure

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 20 Oct 2010 23:20:09 +0200

> .. geez really. Like what where are the examples of the harm? So who put

I am trying to understand where there are misunderstandings and differences in insight. And I think you might have read 5.1 different than intended:

It is not trying to speak about  data that is leaked from "internal" to "public" DNS installs. But it tries to make a more generic point that solutions that are engineered for environments that are supposed to be closed will leak to the public Internet. With that comes a responsibility to design those solutions and protocols in such a way that they will have the appropriate security, privacy, and scalability properties.

?

--Olaf
 (speaking for myself)

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Oct 2010 17:39:16 -0400

> time in Prague on a BOF that will never be chartered.

	well... if its done faster/better outside the IETF by an industry
group...

Well if that is the preference of the IAB and the IESG then so be it. What
we need now is clarity on the architectural status for this class of
application drafts etc and this document is not providing it. After almost 4
years of ongoing discussion on how to deal with this data in a IP context
now we have this "Well guys maybe this isn't such a good idea."

---

From: bill manning <[email-masked]>
Date: Wed, 20 Oct 2010 15:06:35 -0700

> I would truly love to see the data you have that backs this up.  Pointers?  (Note that this is not rhetorical -- I'm doing some work right now in which this info would be quite helpful).

	i can show the auth data I have, the (to me) data from large caches is suggested in places like OARC and elsewhere that suggest caching is
	a huge factor is the scaling of the DNS.   I've been flogging the idea that it would be an excellent idea to correlate data flows between stub/cache/auth
       servers and maybe have a couple of interested parties.  if your doing similar work, we should talk in a more restricted setting.

> I thought the (vast) over-provisioning of the root servers was to cope with DDoS attacks.

	this (leaking) is a DDoS... :)

-- bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Oct 2010 19:31:14 -0400

Looking at the rest of the document, I do find that it is written rather
oddly.

The document essentially says 'the DNS is designed with these assumptions in
mind, therefore applications must take these into account'.

I would hope that an Internet Architecture Board would look at the features
that applications require and propose an architecture to support them.

There are some DNS architectural assumptions that cannot be changed. For
example, ownership of names must be unambiguous. There cannot be two
example.com domains being run by separate parties. But that does not mean
that the mappings within that namespace must be universal and context free.
The market has abandoned the notion that DNS mappings be global long ago.

The weakest DNS architectural idea is the notion that DNS resolvers are
untrusted. This is simply wrong. Every DNS resolver performs a trusted role.
The failure to recognize this fact in the DNS architecture is an
architectural failure of the type I would like to see the IAB saying 'this
is wrong, this is bad, this should change'.

There is no reason intrinsic to the DNS design that requires hosts to engage
in promiscuous resolution. There are obvious health risks to doing so.
Deprecating this bad architectural commitment allows many other DNS flaws to
be mitigated, the vulnerability to traffic analysis and denial of service,
for example.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Oct 2010 09:28:09 +0900

> So what is your point ..you don't use phone numbers so the rest of the

As PSTN will disappear, E.164 will also disappear, because there
will be no PSTN operator to maintain E.164 number space.

Or, do you think people may keep paying for the maintenance fee
for e164.arpa. subtree in addition to maintenance fee for their
own domain names?

I don't think so.

Note that I wrote in my paper for INET2000 that:

   http://www.isoc.org/inet2000/cdproceedings/4a/4a_3.htm

   However, it is obvious that the telephone network will be
   replaced by the Internet, and will eventually disappear.
   At that time, most of the features of VoIP protocols will
   become obsolete.

and e164.arpa. will be obsolete.

							Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Oct 2010 03:14:00 +0200 (MEST)

> untrusted. This is simply wrong. Every DNS resolver performs a trusted role.

Nope, just the opposite.  Name to address translation is meant to
be an extremely lightweight and fast service.

Hostnames are NOT supposed to be trusted in any way and it a serious
misconception to think they're trusted.

If you want to authenticate your peer, use something like an SSH host key.
The routing of datagrams on the internet is also untrusted, so any notion
that a service that translates hostnames into IP-Addresses should be
trusted is fatally flawed and is totally ignorant about the fundamental
architecture of the internet.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Oct 2010 12:55:10 +1100

In message <[email-masked]>, Martin Rex writes
> be an extremely lightweight and fast service.

The DNS is not just name to address translation.
 
> If you want to authenticate your peer, use something like an SSH host key.

And how do you know you should trust the host key the remote machine presents?

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Oct 2010 22:06:15 -0400

Exactly,

The pre-DNSSEC application architecture for DNS is now obsolete.

We have at this point only developed a technical infrastructure for securing
DNS responses. Developing the application architecture to leverage that
opportunity still lies ahead of us.

But even in the new world of DNSSEC with end-to-end authentication, the
resolver plays a role that requires trust and thus should be chosen and
trusted.

On Wed, Oct 20, 2010 at 9:55 PM, Mark Andrews <[email-masked]> wrote:

> > > untrusted. This is simply wrong. Every DNS resolver performs a trusted
> role
> > .
> >

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Oct 2010 11:22:28 +0900

> be an extremely lightweight and fast service.

DNS has been extremely lightweight, fast and trustable service

> misconception to think they're trusted.

DNS, including but not limited to DNSSEC, has been weakly secure
and is as secure as, for example, PSTN function for callees to
know callers number, which is trusted upon by most mobile phone
users.

You can just trust network and domain operators of the Internet,
just as you can trust network and E.164 number operators of PSTN.

						Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Oct 2010 19:51:07 -0700

> will be no PSTN operator to maintain E.164 number space.

"In the long run, we're all dead" -- John Maynard Keynes

In the intervening decades, it is probably worthwhile dealing with the reality that PSTN (and hence E.164) exists.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Oct 2010 14:13:51 +0900

David Conrad wrote:

> In the intervening decades, it is probably worthwhile dealing
> with the reality that PSTN (and hence E.164) exists.

But, why do we have to be bothered by proposals for more efficient
processing of the declining and disappearing E.164?

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Oct 2010 07:57:59 -0400

It is quite possible and rather likely that the PSTN will disappear but the
numbering system will not.

Telephone numbers have a major advantage of being able to be dialed from a
12 button keypad without kludges. China and other countries that
have syllabaries rather than alphabets are likely to prefer numbers as a
naming system since they use a limited character set that can be expressed
directly on a keyboard.

What I expect to disappear is digit-by-digit dialing. Telephone numbers are
only dialed digit by digit by the user in exceptional cases today. The need
to support efficient dialing in this fashion seems to arise as an artifact
of a poorly integrated system.

On Wed, Oct 20, 2010 at 10:51 PM, David Conrad <[email-masked]> wrote:

> In the intervening decades, it is probably worthwhile dealing with the
> reality that PSTN (and hence E.164) exists.
>
> Regards,
> -drc
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 21 Oct 2010 10:37:08 -0400

Because.  Its not declining or disappearing .. just ask the mobile operators
who have added several billion new mobile handsets over the past few years.

Analog POTS is certainly dying but the E.164 namespace is doing even better
than domain names.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Masataka Ohta
Sent: Thursday, October 21, 2010 1:14 AM
To: David Conrad
Cc: [email-masked]
Subject: Re: draft-iab-dns-applications - clarification re: Send-N

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Oct 2010 16:58:08 +0200 (MEST)

> > The DNS is not just name to address translation.

It doesn't really matter what DNS translates, all translations
are equally untrusted.

The architecture of the internet is based on good faith and best effort.
DNS is _no_ different.

What we're fighting about is probably not what exactly DNSSEC is
about, but how we define the meaning of "trusted".  A lot of folks
seem to argue based on the assumption "faith" == "trust".

> > And how do you know you should trust the host key the remote machine

Use whatever you feel comfortable with.  Out-of-band pen&paper.
Leap-of-faith on initial encounter.

What do you do yourself when you meet some person for the first time?
Do you ask them for their passport or legal ID-card (not that it would
make much of a difference)?  And what do you do on repeated encounter?

The traditional human concept of "trust" between persons is
a combination of "leap-of-faith on initial encounter" with non-negative
experience and getting accustomed to sensoric input patterns to some
of the other persons's biometrics (which requires memorizing those patterns).

And both, evolution and every day life shows us that collecting memories
about previous encounters can help us to significantly reduce our
susceptibility to impersonation.

> The pre-DNSSEC application architecture for DNS is now obsolete.

That is a common misunderstanding of DNSSEC.

The difference between DNS and DNSSEC is *only* about the
distribution/delivery of the data, not about the trustwortyness of
the data.  The error protection in the original DNS distribution protocol
was only against statistical/accidental errors, not against malicious
targeted attacks.  DNSSEC protects the distribution/delivery of the data
from malicious targeted modification, and nothing else.

And even if there existed a trusted naming service, that would still
not allow you to distinguish friend and foe by their hostnames,
because knowing the identity of something does not necessarily
reveal its intentions.

I do not expect that DNSSEC will put phishing to an end, and neither
to I expect DNSSEC to prevent further filesharing lawsuits against
internet users.

> resolver plays a role that requires trust and thus should be chosen and
 
We're back to differing definitions of "trust".

The size of the human monkeysphere is around 150 entities, the number of
nodes on the internet is in the billions.  So no matter how hard you try,
>99.999% of the internet is going to be remain untrusted to every
internet user (for any humanely meaningful definition of "trusted").

Personally, I think it would be much more sensible to help internet users
to improve the effective trust inside their own monkeysphere, instead
of fighting about how we might reduce the untrusted part of the internet
from 99.999999% to 99.999998%.

-Martin

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 21 Oct 2010 16:10:28 +0100

Hi folks,
What you're saying is that you are not the target customer for this stuff.
I would guess that few people on this list are either.

That does not however mean that a few billion users around the world mostly
use smartphones or PCs; either that or I have missed the heaps of 12 digit
phones at landfill sites, or bulging re-cycling warehouses.

Everyone MOSTLY calls from a small contact list, and the same holds for the
group of people who call them. The goal is to support them when they don't.
I don't know how long a phone number in Marrakech should be. Rather than
place an International call to find out I've missed a digit, I would like
a scheme to help me, ideally before I even get into the voice application.
I guess I could use google, but that is too Web 2.0 for my taste or patience.

As for overlap signalling being obsolete -- it depends on your definition.
I'm pretty sure every equipment provider would be VERY happy if big Telcos
removed the requirement, and the requirement to continue to support it for
years. EnBloc dialling has definite benefits, but until landlines ALL go
away we're stuck with digit-by-digit dialling.

I'm AssUMing that you are not suggesting that the IETF is soooo slow that
by the time anything is specified, we'll all be using wristwatch mobiles?

all the best,
  Lawrence

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Oct 2010 20:00:36 +0200 (MEST)

> away we're stuck with digit-by-digit dialling.

I fail to understand where the really big problem is with dialing.

Privately and at home I'm using either mobile or DECT, and in both
cases I type the number in its entirety before "picking up", simply
because I can edit typos without having to start over.

All of the DMTF-capable phone should have a "#" button, and when
doing navigation in voicemail systems and pre-paid account loading
one often needs to use that button already.

Covering the legacy dialing with a time-out should IMHO be sufficient
to maintain support for *old* equiment and also provide a slight
motivation for end users to upgrade if they don't like pressing "#"
or waiting for the timeout before the connection is established.

Probing each time when a new digit arrives does not seem reasonable to me.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Oct 2010 04:19:23 +0900

> Because.  Its not declining or disappearing .. just ask the mobile operators

FYI, KDDI, the second largest mobile operator in Japan, has just
announced to support skype as a formal application.

It's inevitable as data traffic is exceeding voice traffic.

It is true that IETF has been stalling on not only IPngs but also
mobile IPs. But mobile architecture will change as the integration
of 3G and WiFi networks proceeds.

> who have added several billion new mobile handsets over the past few years.

New *SMART* mobile handsets are ready to run skype as an application.

> Analog POTS is certainly dying

ISDN, which was about to have 10M subscribers in Japan before
DSL era, is dying even more rapidly.

> but the E.164 namespace is doing even better
> than domain names.

The question I already asked is: who pays for it.

Clearly, mobile users won't want to pay to maintain E.164 for
POTS.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Oct 2010 15:34:53 -0400

My point was that folk who are looking at this mechanism as an optimization
within the existing boxes should also look at the fact that the box
boundaries are wrong and inefficient.

The use experience should be unaffected by this issue. A telephone call has
ten or so numbers and a DNS round trip should complete before the user types
in the next digit on modern networks.

So what we come down to is attempting to save a few round trips and that
does not excite me greatly as the number of phone calls per day is only in
the billions. And ten billion packets is not such a big deal in the modern
Internet.

It is a worthwhile thing to do, but its a minor detail.

---

From: John Levine <[email-masked]>
Date: 21 Oct 2010 22:42:42 -0000

>Probing each time when a new digit arrives does not seem reasonable to me.

Hi.  I have a couple of phones on my desk, but the one I use the most
is a two-line phone, one's an ILEC POTS line, the other's an analog
VoIP terminal adapter.  I have some numbers on speed dial but I often
dial numbers one digit at a time.

I dunno about you, but it seems utterly unreasonable to demand that we
change the way we've been placing calls for the better part of a
century merely to avoid a few DNS lookups.  I thought computers were
supposed to make life easier for people, not the other way around.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Oct 2010 11:06:23 +1100

In message <[email-masked]>, Martin Rex writes
> It doesn't really matter what DNS translates, all translations

Actually it's not these days.  I can trust some answers from the DNS
more than other answers from the DNS.
 
> seem to argue based on the assumption "faith" == "trust".

I can trust that some answers have not been tampered with in transit
others I can't.  Whether the original data is was "good" or not is
another question.  I need to also make a decision about whether to
trust that data or not but I can't do that as safely without first
knowing that it hasn't been tampered with in transit.

For email we can eliminate MITM interception attacks now that we
have DNSSEC.  The answers to the MX, A and AAAA lookups can now be
secured.  This gives you a MX record (explict or implicit) which
is reasonable to trust.  From that you know who you are supposed
to be talking to and what CERT should should be presented in response
to STARTTLS.  The only thing missing is a way to say that you should
expect to have STARTTLS offered to you when you make the SMTP
connection.  A simple solution to that would be to have SMX (Secure
MX) record which is otherwise identical to a MX records but indicates
that STARTTLS is offered by the mail exchangers for this mail domain.

Even without SMX you have stopped redirection by returning fake MX
RRsets or fake A / AAAA records.  You now need to redirect/intercept
the TCP connections.  You have made the job of intercepting email
harder.

> make much of a difference)?  And what do you do on repeated encounter?

It depends on what my relationship with them will be.
 
> susceptibility to impersonation.

We also have introductions.

People also read body language etc. none of which is available digitally.

Mark

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Oct 2010 07:27:03 +0000

> supposed to make life easier for people, not the other way around.

Indeed, and it's not just DNS lookups - per my original message it's also a potentially significant saving in the number of SIP transactions.  Those are _much_ more resource intensive than a DNS lookup.

Ray

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Oct 2010 00:11:55 -0400

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" <[email-masked]> wrote:

And finally, regarding:

---

From: todd glassey <[email-masked]>
Date: Fri, 22 Oct 2010 09:05:13 -0700

> use that is rapidly becoming obsolete.

Amen

-- 
//-----------------------------------------------------------------

This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.

Thank you for your cooperation.

---

From: Martin Rex <[email-masked]>
Date: Fri, 22 Oct 2010 21:42:37 +0200 (MEST)

John Levine wrote:
> I wrote:

You didn't quote my answer to your concerns (inserted above).

> I have some numbers on speed dial but I often dial numbers one digit
> at a time.

Likely >99% of _humans_ dial phone numbers one digit at a time when
they "dialing".  That doesn't mean that the technology that establishes
the actual communication link must continue to start beating a path
for every new digit.

20 years ago the German Telekom still had mix of old mechanic
phone switches and newer digital switches.  If the equiment on your
end supported and was using DTMF but the call was routed over old
switches, you could listen to the clicking sounds from the old
rotary hardware how the call was routed to its destination, long
after you had finished "typing" the number on your DTMF phones keypad.

> supposed to make life easier for people, not the other way around.

I'm terribly sorry, I never intended to convey such a message
(and I still believe I didn't).

I'm all in favour of full backwards compatibility!

For those that have come to love slow dialing, I'm all in favour
of retaining the _ORIGINAL_ user experience, waiting for the
rotary mechanical technique to complete its magic before the
communication link is established.  But since the telephone
network backbone no longer provides this user experience,
it needs to be emulated by all VoiP equipment that offers
attachment of two-wire analogue phones.

I'm sorry for my insensitivity to describe the enlighenting performance
of the classical phone user experience by the VoiP equipment emulation
as a "timeout" (preceding the instant connection setup with the
full and final number).

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 23 Oct 2010 06:04:50 +0900

Peterson, Jon wrote:

> However, if we assume that the delay incurred by that timer is
> intolerable,

Use reasonable timer, as you seems to be assuming a few
minutes of delay.

It's POTS, which means a few seconds of delay can not be
intolerable.

> "essential function in the transition from analog POTS to
> SIP based communication."

You say it's "analog POTS". Forget requirements like "real-time"
dialing.

And, remember that the calls of the most advanced POTS of digital
ISDN is delayed a several seconds after dialing, because ISDN has
a wonderful feature of optional and variable length subaddresses.

Remember also that the delay occurs for all the calls even though
virtually no one is using the subaddresses.

						Masataka Ohta

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 23 Oct 2010 17:00:41 +0200 (CEST)

Hi Jon

On Thu, 21 Oct 2010, Peterson, Jon wrote:

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

Which E2MD charter do you refer to in this part of your email?
Is it the one we prepared for Maastricht (IETF-78) as publised on:

   http://trac.tools.ietf.org/bof/e2md/trac/wiki/ProposedCharter

or some older version or even both? May I ask you clarify this.

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 24 Oct 2010 15:42:48 +0100

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 25 Oct 2010 16:39:59 -0400

I refer to any past, present or future version of the charter that departs from the assumption that the DNS is the right protocol to address a set of discrete problems that includes the candidate drafts of the original E2MD BoF. As I read the version you point to below, for example, it does suggest that the overlap dialing optimization requirement should be addressed with a DNS-based solution. I think it remains unclear whether a DNS-based proposal is the optimal way to address overlap dialing.

Jon Peterson
NeuStar, Inc.

On 10/23/10 11:00 AM, "Bernie Hoeneisen" <[email-masked]> wrote:

Hi Jon

On Thu, 21 Oct 2010, Peterson, Jon wrote:

> 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
> intends in the future to capture the ongoing discussions we've now begun about these

cheers,
  Bernie

--

http://ucom.ch/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 25 Oct 2010 16:42:43 -0400

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" <[email-masked]> wrote:

----

all the best,
  Lawrence