Subject: [Enum] Itternation in ENUM, a disconnect with DDDS?

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 14 Aug 2000 11:02:03 -0500

I have been working on a number of "use cases" with ENUM and discovered I
don't know how to do a number of common numbering-plan actions using NAPTRs.
Is this a major issue?

1) Renumbering:

The telephone system (at least in the US) frequently renumbers entire blocks
of numbers to use another prefix.  This is commonly called "area code
split".  When doing such a split, there is typically a period of "permissive
dialing" where one can dial either a new number or the older number.  In the
cases I am most familiar with, the renaming changes a prefix.  (I have seen
in other countries where new digits are added or where digits may even be
deleted ... I have no idea if there is a "permissive" interval in these
transitions)

In DNS, the DNAME record provides a perfect fit structurally, by enabling an
entry in the DNS that results in a DNS prefix substitution and a new query.
However, this power does not assist in the construction of the correct URI
from the retreived NAPTRs.  Using DNAME, one can have two paths to reach the
same node in the tree.  If the resulting URI has telephone number components
within it, the NAPTR replacment algoritm potentially needs to be different
for each of the two paths, in one case replacing an "old" prefix and in the
other, not.  Where in "normal" DNS, the substitution and re-query with
Cnames and Dnames is transparent to the client, in ENUM using NAPTRs, it is
not.

So, rather than using DNAMEs, I figured you could use NAPTRs and use
itteration to get the "preferred" number, and then requery.  The DDDS logic
supports the itterative query and ultimately returns the approprate set of
NAPTRs... But because the Regexp applies to the ORIGINAL string, it did not
solve the problem, it simply pushed more work on the client.  When I try to
apply the regexp to derive the URI, there is a good chance based on the
query path that the right substitution won't happen.

2) Address Completion:

While this is technically out-of-scope, we have been making design decisions
based on being able to apply different Regexp logic to E164 and incomplete
e164 numbers.  (Whether to keep or ditch the "+".)

If one queries using an incomplete number using a locally significant DNS
root, such as 1.1.2.3.4.5.6.7.8.9.nanp.us, one could be returned a NAPTR
record with a regexp that results in a full e164 number and causes a
subsequent query for the complete e164 record
1.1.2.3.4.5.6.7.8.9.1.e164.arpa.  So far, easy and useful.

However, I encounter the same problem as above.  Again, assuming the URI has
telephone number components within it, the E164 node needs to potentially
have two NAPTR entries, one for each of the two paths used to retreive the
records.  The poor sucker trying to make his IPtelephone work now needs to
figure out all the possible paths to construct a rule-set that reliably
works.  When combined with short digit (local) dialing and private
numbering, we can end up with tens of NAPTR records for a few simple
services.

There are a number of other interesting examples in this space...  For ENUM,
it seems clear to me we need to provide a variation on DDDS that permits the
query itterations to modify the initial string, not just the query.  Without
it, each end-node, each NAPTR record set needs to be modified each time
there is a structural change or addition to the numbering plan..... 

Can we modify the rules to say that the replacement algorithm applies to an
"un-dot-stuffed, un-prefixed" DNS string returned in the NAME field of the
DNS response containing the NAPTRs?   It seems that would work for at least
the two examples above, using either DNAME, CNAME, or other NAPTR
itteration.

Comments?

Greg V.

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Aug 2000 09:34:29 +0200

At 11.02 -0500 00-08-14, Vaudreuil, Greg M (Greg) wrote:
>But because the Regexp applies to the ORIGINAL string, it did not

I agree it would be interesting to both be able to change the orginal 
string and give back the next domainname to use. But that is not the 
case.

So, one have to in the terminal NAPTR write a regexp which matches 
all different kind of input strings, and one common one is '.*', i.e. 
match everything.

>numbering, we can end up with tens of NAPTR records for a few simple

Well, I rather think the NAPTR should look like:

1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "E2U+LDAP"
    "!(.*)!ldap://....\1" .

...where the .... is replaced by a correct LDAP URI content.

You can also do

1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "mailto+E2U"
    "!(.*)!mailto:\[email-masked]" .

etc etc

I.e. in some cases it is a good thing to keep the orginal string.

     paf