Subject: RE: [Enum] ENUM interworking

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

Penn,

At 11:27 AM 10/31/2001 -0500, Pfautz, Penn L, NNAD wrote:
>PLP: The idea seemed to be that the e164.arpa Tier 1 would have a standard
>NS record pointing to the alternate
>registry. This would cause the query to be made to that registry  with an
>e164.arpa domain, i.e. <phone_number_backwards_with_dots>.e164.arpa. Since
>the presumption is that the alternate registry stores its NAPTR under a
>proprietary domain, e.g. joesenum.com, there would be a CNAME record in
>the alternate registry that would cause a new query to be done on
><phone_number_backwards_with_dots>.joesenum.com.

This is not intended to be as flippant as it sounds, but what problem are 
we trying to solve here?  Can you point me to a document that is describing 
the architecture in which using CNAMEs would be appropriate?

Tnx,
-drc

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

---

From: "Jordyn A. Buchanan" <[email-masked]>
Date: Thu, 01 Nov 2001 13:35:13 -0500

At 08:00 PM 10/31/2001 -0800, David R. Conrad wrote:

>we trying to solve here?  Can you point me to a document that is 
>describing the architecture in which using CNAMEs would be appropriate?

The problem trying to be solved is that some records may be stored under a 
different domain name.  For example, the owner of +1.212.555.1212 might 
wish to store their NAPTR records at 2.1.2.1.5.5.5.2.1.2.1.example.ie, but 
still wishes the name to resolve using the "golden tree" and a lookup under 
e164.arpa.  CNAMEs were suggested as a way to accomplish this.

If your question is, "why would someone want to do that instead of just 
delegating within the same domain using NS records?" then I have no idea.

Jordyn

---

From: "Mark Harris" <[email-masked]>
Date: Thu, 1 Nov 2001 14:43:41 -0500

Hi Jordyn...

>For example, the owner of +1.212.555.1212

Your example is perfect.  "555.1212" is a directory assistance number.  If I
dial 555.1212, I will almost certainly need to be routed differently than
you will, even in the same area code, especially if we have different TSP
carriers.  "Multiple places, One Telephone #"

That is one of many reasons for ENUM needing to be multiple domains, outside
of the Golden tree.
Other reasons are listed in Appendix 1 of the SGA Adhoc on ENUM Report...

Regards,
Mark

www.EnumNIC.net
www.EnumForums.org

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jordyn A. Buchanan
Sent: Thursday, November 01, 2001 1:35 PM
To: David R. Conrad; Pfautz, Penn L, NNAD; Kevin McCandless;
[email-masked]'
Cc: [email-masked]'; Bob Wienski
Subject: RE: [Enum] ENUM interworking

Jordyn

---

From: Bill Manning <[email-masked]>
Date: Thu, 1 Nov 2001 11:51:00 -0800 (PST)

% 
% Hi Jordyn...
% 
% >For example, the owner of +1.212.555.1212
% 
% Your example is perfect.  "555.1212" is a directory assistance number.  If I
% dial 555.1212, I will almost certainly need to be routed differently than
% you will, even in the same area code, especially if we have different TSP

	me thinks you have made at least one assumption here.
	please bear with me. I think that it is true that
	there is only one "delegation" at  2.1.2.1.5.5.5.2.1.2.1.e164.arpa.

	there may be several totally sad poodles (TSP) that wish to 
	provide answers for an unqualified request made to:
	2.1.2.1.5.5.5<the remaining parts of the domain unspecified>
	and it seems that you do not believe this can be done.
	
	if that is to be supported, based on the "credentials" supplied
	by the requestor, this can be done within the existing DNS,
	retaining the single delegation point. Some of the techniques
	are simple to implement, some are more "feature-rich" and 
	such techniques are not constrained to a single implementation.

	but you might mean something else, and if so, I am sorry for 
	the distraction.
	
--bill

---

From: "Mark Harris" <[email-masked]>
Date: Thu, 1 Nov 2001 15:34:47 -0500

Hi Bill:

The challenge lies with the fact that multiple entities (as part of an
assignee group) have rights to use the telephone number 1.212.555.1212, and
therefore, multiple entities would have rights to use...

2.1.2.1.5.5.5.2.1.2.1.e164.arpa

Therefore, to eliminate the problem; a framework for dealing with this issue
is to have the user go to a domain operated by their network provider....

2.1.2.1.5.5.5.2.1.2.1.e164.isp.com  (for example)

This number would provide, in this case, directory assistance related
service to the user.  However, if the user always goes to the domain of
their network, and...

If the user puts in a different telephone number...

7.5.5.8.8.7.6.0.4.5.1.e164.isp.com  (my phone number)

and let's suppose the number is registered in...

7.5.5.8.8.7.6.0.4.5.1.e164.arpa

What is the easiest way for the request to be routed to "e164.arpa" from
"e164.isp.com"

What record would work the best... DNAME, CNAME, a Redirect URI in the
NAPTR, or something else?

Regards,
Mark

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 2:51 PM
To: [email-masked]
Cc: Jordyn A. Buchanan; David R. Conrad; Pfautz Penn L NNAD; Kevin
McCandless; [email-masked]; [email-masked]; Bob Wienski
Subject: Re: [Enum] ENUM interworking

%
% Hi Jordyn...
%
% >For example, the owner of +1.212.555.1212
%
% Your example is perfect.  "555.1212" is a directory assistance number.  If
I
% dial 555.1212, I will almost certainly need to be routed differently than
% you will, even in the same area code, especially if we have different TSP

--bill

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Nov 2001 12:34:57 -0800

>is to have the user go to a domain operated by their network provider....

They may (and will) have multiple network providers, not just one.

So, the real requirement is that the assignment of the DNS name (enum 
string) must be coordinated with the assignment of the PSTN string.  This 
does not require that the DNS name operation be by the entity assigning the 
PSTN string.  It requires that they collaborate.

Because there will be entries under the DNS name for services that are 
offered by competitors to the entity assigning the PSTN string, there is a 
very strong argument for ensuring that the DNS registry be an independent 
third party.

d/

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

---

From: Bill Manning <[email-masked]>
Date: Thu, 1 Nov 2001 12:45:40 -0800 (PST)

ah... (and he did err, not knowing the DNS).

 so you anticipate each enduser configuring their own search list?
 I would have thought that it would be desirable to just take advantage
 the normal DNS techniques.  Why not let the holder of the delegation 
 encode the forwarding rules to "punt" the request to the appropriate
 network provider?  To clarify, the DNS admin for a delegation point
 encodes forwarding rules to the various service providers. So you
 have one delegation point and multiple parties being able to respond
 to queries, based on the offered "credentials" of the querier?  Fits 
 the current DNS model, is easy to deploy, and reduces the need to have 
 the enduser building configurations.  And it has the added advantage
 of separating the DNS admin function from the service provider function. :)

 I think this does -exactly- what you have described, while allowing
 the DNS to retain its coherency.  Or am I still off in the weeds?

% 
% Hi Bill:
% 
% The challenge lies with the fact that multiple entities (as part of an
% assignee group) have rights to use the telephone number 1.212.555.1212, and
% therefore, multiple entities would have rights to use...
% 
% 2.1.2.1.5.5.5.2.1.2.1.e164.arpa
% 
% Therefore, to eliminate the problem; a framework for dealing with this issue
% is to have the user go to a domain operated by their network provider....
% 
% 2.1.2.1.5.5.5.2.1.2.1.e164.isp.com  (for example)
% 
% This number would provide, in this case, directory assistance related
% service to the user.  However, if the user always goes to the domain of
% their network, and...
% 
% If the user puts in a different telephone number...
% 
% 7.5.5.8.8.7.6.0.4.5.1.e164.isp.com  (my phone number)
% 
% and let's suppose the number is registered in...
% 
% 7.5.5.8.8.7.6.0.4.5.1.e164.arpa
% 
% What is the easiest way for the request to be routed to "e164.arpa" from
% "e164.isp.com"
% 
% What record would work the best... DNAME, CNAME, a Redirect URI in the
% NAPTR, or something else?
% 
% Regards,
% Mark
% 
% 
% 
% -----Original Message-----
% From: Bill Manning [mailto:[email-masked]]
% Sent: Thursday, November 01, 2001 2:51 PM
% To: [email-masked]
% Cc: Jordyn A. Buchanan; David R. Conrad; Pfautz Penn L NNAD; Kevin
% McCandless; [email-masked]; [email-masked]; Bob Wienski
% Subject: Re: [Enum] ENUM interworking
% 
% 
% %
% % Hi Jordyn...
% %
% % >For example, the owner of +1.212.555.1212
% %
% % Your example is perfect.  "555.1212" is a directory assistance number.  If
% I
% % dial 555.1212, I will almost certainly need to be routed differently than
% % you will, even in the same area code, especially if we have different TSP
% 
% 	me thinks you have made at least one assumption here.
% 	please bear with me. I think that it is true that
% 	there is only one "delegation" at  2.1.2.1.5.5.5.2.1.2.1.e164.arpa.
% 
% 	there may be several totally sad poodles (TSP) that wish to
% 	provide answers for an unqualified request made to:
% 	2.1.2.1.5.5.5<the remaining parts of the domain unspecified>
% 	and it seems that you do not believe this can be done.
% 
% 	if that is to be supported, based on the "credentials" supplied
% 	by the requestor, this can be done within the existing DNS,
% 	retaining the single delegation point. Some of the techniques
% 	are simple to implement, some are more "feature-rich" and
% 	such techniques are not constrained to a single implementation.
% 
% 	but you might mean something else, and if so, I am sorry for
% 	the distraction.
% 
% --bill
% 

-- 
--bill

---

From: "Mark Harris" <[email-masked]>
Date: Thu, 1 Nov 2001 16:40:57 -0500

Hi Bill:

Sounds Great.  (you're not in the weeds)  :-)

We'll will have to explore the various methods (and issues)
in this "punting" process.  (credentials, encoding, forwarding, etc.)
Thanks for the input.

Regards,
Mark

www.EnumNIC.net
www.EnumForums.org

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 3:46 PM
To: [email-masked]
Cc: Bill Manning; Jordyn A. Buchanan; David R. Conrad; Pfautz Penn L
NNAD; Kevin McCandless; [email-masked]; [email-masked]; Bob
Wienski
Subject: Re: [Enum] ENUM interworking

%
% Hi Bill:
%
% assignee group) have rights to use the telephone number 1.212.555.1212,
and
% Therefore, to eliminate the problem; a framework for dealing with this
issue
% % Your example is perfect.  "555.1212" is a directory assistance number.
If
% % dial 555.1212, I will almost certainly need to be routed differently
than
% % you will, even in the same area code, especially if we have different
TSP

--
--bill

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 02 Nov 2001 07:16:43 +0100

--On 2001-11-01 13.35 -0500 "Jordyn A. Buchanan" <[email-masked]>
wrote:

> The problem trying to be solved is that some records may be stored under
> a different domain name.  For example, the owner of +1.212.555.1212 might
> wish to store their NAPTR records at 2.1.2.1.5.5.5.2.1.2.1.example.ie,
> but still wishes the name to resolve using the "golden tree" and a lookup
> under e164.arpa.  CNAMEs were suggested as a way to accomplish this.
> 

I would propose two major proposals for how to solve this problem:

(a) Using CNAME:

Add to some zone the following record:

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN CNAME 2.1.2.1.5.5.5.2.1.2.1.example.ie.

and to the correct zone at example.ie:

2.1.2.1.5.5.5.2.1.2.1.example.ie. IN NAPTR ....

(b) Using NS records:

Add to some zone the following record:

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.

and a zone to the ns.example.ie server which looks like

2.1.2.1.5.5.5.2.1.2.1.example.ie. IN SOA ....
2.1.2.1.5.5.5.2.1.2.1.example.ie. IN NS ns.example.ie.
2.1.2.1.5.5.5.2.1.2.1.example.ie. IN NAPTR ....

Note that in example (b) the ns.example.ie. nameserver need to have one
zone per number it takes care of, while in example (a) it can have more
than one number in each zone. Which one of these two proposals is the
easiest I don't know. There are pros and cons with both.

If noone objects, I would like to declare these two ways of referencing the
leaf node in an ENUM context as the "preferred ones".

BUT, I also see that we have other proposals, and one is DNAME. I don't see
any exciting new things with DNAME which make things easier than (a) or (b)
above. And, given the worries about DNAME administration, the number of
lookups needed etc, I would like to have DNAME on the list for
alternatives, but without compelling arguments why it is better than (a)
and (b) above, not as a real alternative.

I accept more alternatives of course, but, would like to get few examples
on how to handle these issues in a document which talks about "DNS 101 in
the ENUM context".

People should read ripe-192, "Simple DNS Configuration Example,"
<http://www.ripe.net/ripe/docs/ripe-192.html>, which might be a document we
can reference. It took over a year to create ripe-192 (belive it or
not)....and I don't want those "basic" discussions here if we can avoid it.

But, specific examples, and then references to RIPE-192 is of course ok. I
think it might be needed as Ripe-192 is pretty basic, and VERY hands on.

     paf

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 2 Nov 2001 08:38:33 +0000

> 	and it seems that you do not believe this can be done.

No, that's not quite the issue.

There are certain telephone numbers, both within and outside E.164 space,
that belong to multiple entities simultaneously. This is because they are
"service codes" rather than numbers per se. It's a while since I studied
the NANP in detail, but if I recall correctly the area code +1 700 works
like this: the local loop provider controls the use of the number space,
so that the destination of a call will depend on the local loop provider.
I presume that +1 NPA 555 1212 fits into this category.

How do we handle such service codes. There is no one person who "owns"
these numbers, so what should the DNS say for them ?

Come to think of it (and again IIRC) +1 700 555 4141 means "tell me who my
long distance carrier is" and therefore varies by *customer*, let along by
local loop operator.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 20 8371 4037
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Jim Reid <[email-masked]>
Date: Fri, 02 Nov 2001 02:04:32 -0800

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

    Clive> There are certain telephone numbers, both within and
    Clive> outside E.164 space, that belong to multiple entities
    Clive> simultaneously. This is because they are "service codes"
    Clive> rather than numbers per se. 

    Clive> How do we handle such service codes. There is no one person
    Clive> who "owns" these numbers, so what should the DNS say for
    Clive> them ?

Unless I'm missing something obvious in the telephony world, this is
simple. Each operator could set up their own private zones for these
service codes. So if devices in that operator's network lookup
1.1.9.e164.arpa (say), they get NAPTR records which point them to the
emergency service provided by that operator. [There would obviously
have to be some checks and procedures to ensure the operator doesn't
unilaterally add service codes or other stuff to their local name
servers. DNSSEC could be useful here to stop naughty things from
happening.] This approach would not work if the service codes overlap
with country codes or whatever: for instance +91 belongs to India.

In that case, there's another solution. The ENUM device recognises the
number as a service code and adds an operator specific extension to
it, creating a unique E.164 number for looking up in the DNS: eg 911
becomes 123456789011 and that's what's looked up. I think that's what
Bill was alluding to earlier. So when a device joins the network, the
operator supplies the list of service codes available on that network
and their corresponding unique E.164 numbers. [They could maybe be
supplied as DHCP options: some hand-waving here!] When the user dials
a service code, the device just looks up the unique E.164 number for
it and we're done.

    Clive> Come to think of it (and again IIRC) +1 700 555 4141 means
    Clive> "tell me who my long distance carrier is" and therefore
    Clive> varies by *customer*, let along by local loop operator.

Presumably this number's NAPTR records would point at something like
an LDAP repository that can answer that question. Remember that the
DNS is a lookup protocol -- "what data is held for this name?" -- so
there are some types of questions you can't reasonably expect it to
answer. Now you could use something like views in BIND9 to provide
different answers for the above number's NAPTR records. But it would
probably not be scalable for this example. It would get very messy and
ugly very quickly: think about what would have to happen when someone
switches long distance provider.

---

From: "Robert H. Walter" <[email-masked]>
Date: Fri, 2 Nov 2001 09:29:40 -0500

> easiest I don't know. There are pros and cons with both.

Hi Patrik,

How does the resolver know to modify the original DNS question from
2.1.2.1.5.5.5.2.1.2.1.e164.arpa. to 2.1.2.1.5.5.5.2.1.2.1.example.ie.?

Bob

---

From: Bill Manning <[email-masked]>
Date: Fri, 2 Nov 2001 07:49:12 -0800 (PST)

% Hi Patrik,
% 
% How does the resolver know to modify the original DNS question from
% 2.1.2.1.5.5.5.2.1.2.1.e164.arpa. to 2.1.2.1.5.5.5.2.1.2.1.example.ie.?
% 
% Bob

	Allow me to speak for paf...

	two things come promptly to mind.

	) BIND's views and ACLs, based on the query source
	) UltraDNS's functional equivalent (that can also direct
	  the answer based on time of query.... :)

-- bill

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 03 Nov 2001 14:43:12 +0100

--On 2001-11-01 14.43 -0500 Mark Harris <[email-masked]> wrote:

> Your example is perfect.  "555.1212" is a directory assistance number.
> If I dial 555.1212, I will almost certainly need to be routed differently
> than you will, even in the same area code, especially if we have
> different TSP carriers.  "Multiple places, One Telephone #"

The numbers you dial on a phone can be of three different kinds according
to the regulator of Sweden which helped me when I wrote RFC 2916:

- A number from E.164 space, which is globally usable, where the caller
  ends up at a specific destination regardless of from where he is calling.
  The number is to be globally resolvable and reachable.

- A number from E.164 space, which is not globally usable, where the
  caller either only can dial it from a specific location, where the
  number is not globally reachable

- A number which is not from E.164 space

RFC 2916 is about E.164 numbers and only the first of these three
categories. Your example is from the second category. 911 / 112 are from
the last category.

When talking about these issues, I differ between a dialing plan and the
global E.164 numbering plan. ENUM is only about the latter.

An ISP / Telco / Enterprise might have interest in using DNS and NAPTR
resource records fo implementation of a local dialing plan in their whole
or part of their network. That is implemented by having the owner of the
network storing the numbers in whatever hierarchy they want (not e164.arpa)
and having software which can distinguish between when "enum-like-service"
is to be used for the dialled number, and when  ENUM-service is to be used
for the global E.164 number plan.

Don't mix these things up...

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 03 Nov 2001 16:09:36 +0100

> 2.1.2.1.5.5.5.2.1.2.1.e164.arpa. to 2.1.2.1.5.5.5.2.1.2.1.example.ie.?

Typo. Sorry.

It should look like this:

(b) Using NS records:

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN SOA ....
2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.
2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NAPTR ....

     paf

---

From: "Robert H. Walter" <[email-masked]>
Date: Sat, 3 Nov 2001 11:34:36 -0500

> 2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NAPTR ....

Hi Patrick,

Much better... Now for the next question.  Why do you recommend creating
a separate zone for each NAPTR record at ns.example.ie?  It is far simpler
to create a single zone at ns1.example.ie for all or any part of "e164.arpa.".

(c) Using NS records:

Add NS records for each E164 to the "e164.arpa" zone

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.
3.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.
4.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.

At ns.example.ie, create an "e164.arpa." zone and add the corresponding
NAPTR records.

e164.arpa. IN SOA ....
e164.arpa. IN NS ns.example.ie.

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NAPTR ....
3.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NAPTR ....
4.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NAPTR ....

You do need an NS record per E164 in the parent zone, but not a zone
per record in the delegated zone.

Bob

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 03 Nov 2001 20:38:05 +0100

> to create a single zone at ns1.example.ie for all or any part of

Because the nameserver at ns1.example.ie MUST NOT be authoritative for the
E.164 numbers it does not have delegations for.

> 4.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.

It might be that you have instead:

2.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.
3.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.se. <--- different server
4.1.2.1.5.5.5.2.1.2.1.e164.arpa. IN NS ns.example.ie.

I.e. numbers which are adjacent might be handled by different servers
(providers of NAPTR record hosting).

> per record in the delegated zone.

See above. It breaks DNS.

  paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 03 Nov 2001 21:36:04 +0100

--On 2001-11-03 15.17 -0500 "Robert H. Walter" <[email-masked]>
wrote:

> Patrik Faltstom wrote:
> Interesting view... Technically, ns1.example.ie MAY BE authoritative for
> anything, but only the delegations in the parent zone will be followed
> by a recursive/iterative resolver, so why does it matter? How is DNS
> broken?  DNS will function perfectly.

The party which queries will get back information when querying
ns.example.ie which is an NS record for e164.arpa. That is called leakage.
When that information is out, queries will be sent to that server, which
authoritatively will respond with NXDOMAIN.

So, just don't go down that path, please.

   paf

---

From: "Robert H. Walter" <[email-masked]>
Date: Sat, 3 Nov 2001 15:58:41 -0500

Ah... Your concerned that the response from ns.example.ie will contain
an NS record for e164.arpa in the authority section and the resolver
will inappropriately cache it.  Subsequent calls through the resolver
will query ns.example.ie for "e164.arpa.", thus resulting in NXDOMAIN
for numbers that have not been delegated to ns.example.ie...

Thanks clarifying your concern,

Bob

> From: Patrik Faltstrom [mailto:[email-masked]]
> Sent: Saturday, November 03, 2001 3:36 PM
> To: [email-masked]; [email-masked]

---

From: "Robert H. Walter" <[email-masked]>
Date: Sat, 3 Nov 2001 15:17:01 -0500

Regards,

Bob

> Sent: Saturday, November 03, 2001 2:38 PM
> To: [email-masked]; Jordyn A. Buchanan; David R. Conrad; Pfautz,
> Penn L, NNAD; Kevin McCandless; [email-masked]
> Cc: [email-masked]; Bob Wienski

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 04 Nov 2001 06:12:30 +0100

--On 2001-11-03 15.58 -0500 "Robert H. Walter" <[email-masked]>
wrote:

> Your concerned that the response from ns.example.ie will contain

I am not concerned. That is how DNS works. :-)

ENUM should only use DNS as a database, and leave to the DNS people to do
DNS operation. Doing "tricks" will _not_ work. It will further never pass
the IETF review of the documents.

   paf