Subject: Re: [Enum] ENUM interworking

From: "David R. Conrad" <[email-masked]>
Date: Wed, 31 Oct 2001 08:11:08 -0800

Kevin,

At 07:30 AM 10/31/2001 -0800, Kevin McCandless wrote:
>After having my ENUM in box full of religious debate I began to wonder if 
>this is the technical department?

Clearly not, but we can try...

>The ENUM Forum that just recently met in Kansas discussed this issue.  We 
>first discussed the use of CNAME records at Tier 1 under 
>RFC2916.  Representatives from both VeriSign and Registrar.com said that 
>this is very burdensome on a database because it would require a double 
>look up every time.

I'm not clear on how CNAME records would be used in this context.  Can you 
explain in more detail?  I'd agree, however, that the use of CNAME could 
result in double lookups (when there are cache misses of course).

>The easiest approach would be to have a resolver for the client.  This 
>resolver would be capable of searching multiple domains for the E.164 
>number.  If one is merely trying to obtain NAPTR records for anything but 
>call setup the resolver approach should work fine.

Unless the same E.164 number is registered in multiple domains in which 
case the resolver will need some heuristics to try to guess which response 
is correct.

>An issue we should be aware of is if ENUM is used for call setup and the 
>resolution of multiple domains takes a large amount of time then this 
>would not be an acceptable delay for the call completion.

This makes the assumption that it is only call setup that is time 
constrained which I'm not sure is a safe assumption.

There are two ways to handle the multiple domain queries, either serially 
or in parallel.  If you make the assumption that the first (positive) 
answer you get back is acceptable, then the parallel approach will not 
differ significantly in time than the lookup in a single domain.

>Circuit switched calls are considered toll grade if they are set up under 
>250ms.  That is a target we should keep in mind if we expect ENUM to be an 
>enabler of call setup and be rooted in multiple domains.

Or in single domains...

Rgds,
-drc

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 31 Oct 2001 11:41:45 -0500

Hi David,

>>would not be an acceptable delay for the call completion.

What is your view about the use of DNAME?

If delay for call completion is the most significant metric,
wouldn't it better to use the namespace for just call resolution
purposes and use other RR types and architectures? Particularly
when the likelihood of a unitary domain public UCI purposes
seems highly unlikely?

Aren't robustness and diminished vulnerability (especially
post 9-11) at least as important attributes as call completion
delay?  Note this subject was ruled out of scope when raised
in the WG last year.  What ENUM architectures and attributes
increase or diminish "signalling" vulnerabilities?  There's
intense interest in this subject these days in Washington
and the industry.

>>250ms.  That is a target we should keep in mind if we expect ENUM to be 
>>an enabler of call setup and be rooted in multiple domains.

Great to see the consideration of alternative architectures
here.

--tony

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Oct 2001 18:55:09 +0100

> What is your view about the use of DNAME?

DNAME only differ from NS records (and the proposed use of CNAME) when you
do a change of the zone name itself. I.e. if you have two domains:

  a.b.c.d.

And, c.d. change it's domain name to x.y.

That change also implicitly changes the names of the domains a and b are
running from a.b.c.d to a.b.x.y and from b.c.d to b.x.y respectively.

DNAME was invented just because it was stated that "rapid renumbering" in
DNS was something that would happen all over the time, and because of this,
DNAME was needed for the "reverse tree" for IPv6 addresses. This to ease
the administration of DNS. Nothing else.

In later discussions, it is clear that the administrator can make much more
damage with the use of DNAME than "normal administration" and because of
that, it is currently viewed that DNAME should _NOT_ be used is possible.

In the case of the e164.arpa tree, what we talk about are normal
delegations, and DNAME is not needed, and neither is CNAME. CNAME would
only work if/when you have a CNAME for the full domain name, while DNAME
can operate at a partial domain name.

So, if you think about how to deploy Enum, use existing mechanisms for DNS,
which include NS records.

Regarding the question about one golden tree or more than one, as David and
Dave have already said, this is _NOT_ an ENUM issue. It is a question on
how DNS works. Reason for one root in DNS, and e164.arpa for E.164 numbers,
is that the party which is to query for a domain name need to know where to
look for the name. Some people have said that "he should be able to choose"
(doesn't work, because he need to choose exactly the same root as the
holder of the E.164 has chosen). Some people have said "do a search in
multiple domains" (doesn't scale, because how to limit the number of such
domains?).

As Dave said, the day someone have come up with a working proposal for how
to handle multiple roots in the DNS, then we can talk again. And, no,
nothing of what is existing is working.

Point is that that discission is NOT to be held on this mailing list.

On the other hand, it is perfectly ok for a company to have a private
"numbering plan" using NAPTR records in DNS and storing those numbers
wherever they want.

That is though not ENUM. For enum to work, the holder of the phone number
and the party querying for the information need to use the same space in
the tree. This because one have no more information than the E.164 when
looking for information.

     paf

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 31 Oct 2001 13:59:13 -0500

Hi Patrik,

>that, it is currently viewed that DNAME should _NOT_ be used is possible.

So the bottom line is that you are concerned about
administrative misconfiguration and lack of conformance
with an ideal namespace construct?

>multiple domains" (doesn't scale, because how to limit the number of such

So....how about two to provide for competition and
redundancy?  While the beauty and efficiency of a
unitary namespace is appreciated, the reality is
that absent a rigidly enforced global regulatory
regime (which we know will not occur), there will
almost certainly be some small number of
namespaces that the marketplace will determine.
It the US, that is a requirement.

So let's proceed to engineer for what is most
likely to occur.

--tony

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Oct 2001 11:19:37 -0800

At 01:59 PM 10/31/2001 -0500, Tony Rutkowski wrote:
>So....how about two to provide for competition and redundancy?  While the 
>beauty and efficiency of a unitary namespace is appreciated,

Glad you appreciate beauty and efficiency.  Evidently you do NOT appreciate 
technical constraints.

Move on, Tony.

The horse you are beating does not even exist, never mind being dead.

d/

ps.  thank you for making clear that you are not really interested in a 
technical discussion but are, instead, only looking for every opportunity 
to keep alive your crusade for a multiple-root system scheme.

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 31 Oct 2001 14:05:31 -0600

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> Glad you appreciate beauty and efficiency.  Evidently you do NOT
appreciate

Technical constraints are, in my opinion, best left to people with the
technical
training and experience to deal with those constraints. The technical
reality is
that the 0:0 .ARPA legacy address space is a very small place, largely
inhabited
by one-dimensional people. That is a technical constraint, because one does
not
have the latitude to use length, width, and height to measure things.

http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:0 .ARPA

It is common knowledge that when one shines a light on objects in dimension
N
they get objects in dimension N-1. A shadow is a 2D object (length and
width)
obtained from shining light on a 3D object. When one shines a light on
objects
of dimension 1, they do not get anything. It should not be surprising to
enlightened
people, if they feel they are not getting anything from these IETF
processses.
It is a technical constraint. Each individual person has decide whether they
want
to constrain themselves in this manner. The vast majority of humans on
planet
Earth choose not to constrain themselves, and they seem to live much happier
and healthier lives.

The one-dimensional worlds and people will not go away. In many respects
people in 2D and 3D need them. Look at .BIZ as an example, there will be a
huge amount of marketing awareness generated and some percentage of the
.BIZ community will progress out of these one-dimensional worlds. They move
on,
and other enlightened people will be waiting for them when they arrive. The
same
can be said for ENUM, all of these efforts by people will eventually help to
shape
the markets in 2D and 3D worlds. Keep up the good work. Keep sending the
people, by telling them to "move on".

Jim Fleming
http://www.DOT-BIZ.com
http://www.in-addr.info
3:219 INFO

---

From: Bill Manning <[email-masked]>
Date: Wed, 31 Oct 2001 12:36:55 -0800 (PST)

% So the bottom line is that you are concerned about
% administrative misconfiguration and lack of conformance
% with an ideal namespace construct?

	... ideal?

	Please elaborate on what would be an ideal namespace 
	construct?  I think of a number of constraints but
	apparently am missing something.
	Something that is resistant to administrative misconfiguration
	and is conformant (but to what? :) are closer to my idea of
	ideal than things which are not. I get the impression that
	you might feel that an ideal construct would allow for 
	arbitrary fragmentation into administrative boundaries while
	retaining the "external" appearance of a single construct.
	Is this correct?

--bill

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 31 Oct 2001 15:59:39 -0500

>         retaining the "external" appearance of a single construct.

Hi Bill,

Rather than assuming the worse case situation of
arbitrary fragmentation, why not consider coordinated,
non-conflicting namespaces to allow for competition
and provide for recovery in case of outages.

If anything remotely like ENUM is going to have
any marketplace acceptance, it will need to be
at least as robust and secure as today's SS7
infrastructure.

--tony

---

From: Bill Manning <[email-masked]>
Date: Wed, 31 Oct 2001 13:07:57 -0800 (PST)

% >         ideal than things which are not. I get the impression that
% >         you might feel that an ideal construct would allow for
% >         arbitrary fragmentation into administrative boundaries while
% >         retaining the "external" appearance of a single construct.
% >         Is this correct?
% 
% Hi Bill,
% 
% Rather than assuming the worse case situation of
% arbitrary fragmentation, why not consider coordinated,
% non-conflicting namespaces to allow for competition
% and provide for recovery in case of outages.

	Hum... again, chasing the ideal, 
	It would seem to me to be desirable to get the 
	coordination and non-conflicting agreements done
	at the outset and then allow the relevent parties
	to freely operate within the constructs that define
	the namespace.  Reducing the need to constantly revisit
	coordination and to ensure that non-conflicting events
	are the norm would lead to faster customer response, which state,
	IMHO, is a characteristic of an ideal.

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Oct 2001 13:56:14 -0800

>>>>> "Tony" == Tony Rutkowski <[email-masked]> writes:

    Tony> Rather than assuming the worse case situation of arbitrary
    Tony> fragmentation, why not consider coordinated, non-conflicting
    Tony> namespaces to allow for competition and provide for recovery
    Tony> in case of outages.

Isn't this the same sort of stance that the alternate root folks
take to justify their position?

Instead of banging on about "non-conflicting namespaces" could you
come up with an algorithm for a DNS resolver to figure out which one
of your hypothetical non-conflicting name spaces it would use to
lookup an arbirary E.164 number? Oh and for extra points please
explain how you'd absolutely guarantee that there are no overlaps or
inconsistencies between these non-conflicting name spaces.