Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 27 Oct 2000 12:34:23 -0500

DNAME is necessary to make real-world number plans work. DNAME is the only
DNS facility available to redirect an entire branch of a domain name tree to
another.... something needed to match the commonly performed redirection of
a telephone number sub-tree.   Maybe this should be more clear in the draft.

DNAME makes possible a number of renumbering situations, where a block of
telephone numbers may temporarily be accessed using one of two or more
prefixes.  For example, during a Dallas area-code split recently I could be
reached at either:

	2.2.7.2.3.3.7.2.7.9.1.e164.arpa
and
	2.2.7.2.3.3.7.4.1.2.1.e164.arpa

one of which was simply a temporary pointer to the other.  

This also occurs where a national authority decides to add a prefix digit to
their number plans.  Duplicating the entire national ENUM hierarchy for
transition is a bit much of a hurdle.
	
It is also helpful when you want a single second-level authority to hold
NAPTR records for internal and external numbering plans such as:

	2.2.7.2.3.3.7.2.7.9.1.e164.arpa (open-world PSTN)
and
	2.2.7.2.dallas.lucent.com  (extension 2272 on local PBX)
and
	2.7.2.2.5.4.2.lucent.com  (location 542, extension 2722)

I want to direct one or more branches to be served by the same zone file for
ease of administration, assurance of consistency, and just plain simplicity.
I need to avoid teaching each client the complete local numbering plan to
initiate a successful query.

Yes, the proper use of DNAME and NAPTR is a real administrative mess with
real danger since the initial string for NAPTR processing is not what the
NAPTR record writer might have thought it was.  We knew that risk before the
ENUM document was published.   Patrick and I went through a long set of
potential applications and topologies, some on and some off the ENUM list.
It turned out that in every case enough attention to detail would make any
combination of application and topology I could think of work provided a
complex enough Regexp is written.  The resolution was simply that one must
be knowledgeable and careful when constructing NAPTR records to make sure
the regexp substitutions work for all initial strings and corresponding DNS
paths used in your branch of numberland.  In particular, be very very
careful if doing anything more interesting than simply pointing to a static
URL.

At the last IETF, there was much hallway conversation about writing an ENUM
profile of NAPTR to reduce the large risk of broken combinations and to
dramatically simplify the task of an application client programmer.  In
particular, it is possible today for a server to serve NAPTRs a likely
simple-minded client is unable to understand (recursion, pattern matching),
or something where an end-customer writes a NAPTRs that breaks when an
up-stream numbering authorities implements something unforeseen
(renumbering).  Initial implementation and experimentation will tell if we
need to profile NAPTR or profile DNS to prohibit Cnames or Dnames in the
ENUM branch.

Greg V.

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Friday, October 27, 2000 11:26 AM
To: [email-masked]
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt

why does this draft use a dangerous and unnecessary DNAME?

randy

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Oct 2000 20:38:11 +0200

>	2.7.2.2.5.4.2.lucent.com  (location 542, extension 2722)

Are you talking about numbering plan or dialing plan here? People 
that work with telephony tell me it is important to distinguish 
between the two.

   paf