Subject: [Enum] Non-Terrminal NAPTRs Considered Harmful

From: "Stastny Richard" <[email-masked]>
Date: Wed, 22 Jun 2005 06:52:29 -0400

Dear all,

The proposal brought forward in 
draft-pfautz-lind-enum-carrier-user-00
raises two issues:

1) Should (user) ENUM and Infrastructure (Carrier) ENUM
implementations be mixed within e.164.arpa?

2) If yes, how should this be done technically?

Regarding 1) I have submitted to the list the position of
ETSI TISPAN WG4 in a previous post, containing the pro and cons.

So I want to concentrate here on issue 2) only:

draft-pfautz-lind-enum-carrier-user-00 proposes
the usage of non-terminal NAPTRs to separate
between user and carrier entries in Tier 1 of
e164.arpa

The usage of non-terminals creates many problems,
(see below), so I consider this harmful.

It is therefore proposed to consider the usage
of terminal NAPTRs to solve the problem at hand,
a technical proposal is also contained below.
This proposal does not solve all problems raised
with non-terminals below, but most of them.

Problems with non-terminal NAPTRs:

The first problem with non-terminals is non-conformant
with RFC3761:

Although RFC3761 allows the usage of non-terminals
(section 1.3 and 2.4), the intrinsic assumption is
that in this case there is no Enumservice used
in the service field (beside E2U). 

Basically the template in RFC3671 to register a
Enumservice cannot be used as is, because in section
3.1.1 is stated:
"A registered Enumservice must be able to function as 
a selection mechanism when choosing one NAPTR resource 
record from another.  That means that the registration 
MUST specify what is expected when using that very NAPTR 
record, and the URI which is the outcome of the use of it.

Specifically, a registered Enumservice MUST specify the 
URI scheme(s) that may be used for the Enumservice, ..."

So a URI definition such as "N/A" or "Any" is not allowed.

Additional problems:

-existing users are forced to move out of e164.arpa
-Non-Terminals are not supported in existing clients
-Non-Terminals involve multiple DNS queries 
-No Glue Records in Non-Terminals 
-Prone to "Error in User" 
-Automatically checking the domain is not easy 
-Pre-existing targets only (the privacy/control problem) 
-Going in Circles, by accident or design 
-Time To Live across domains 
-Etc.
I think Lawrence is here better suited to explain these
problems more in detail, if required or requested.

Proposal to use terminal NAPTRs

It is therefore proposed to use terminal NAPTRs
for this purpose:

I propose to reuse the Enumservice "enum" as specified
in ETSI TS 102 172 for redirection:

This Enumservice uses the "tel:" URI to instruct the
ENUM client to launch another ENUM query for the
E.164 number given in the "tel:" URI. The purpose is
to allow a user who has say three different E.164 numbers 
registered in ENUM to point two of this numbers to the
third and maintain the real NAPTRs only in the domain
of the third.

The default assumption with the tel: URI as given is
that the domain to query is e164.arpa (ENUM)

If now an additional parameter is defined for the tel: URI
e.g. ";enum-context=foo.bar", the behaviour could be 
exactly the same, except that in step 4. of section 2.4
in RFC3761 instead of e164.arpa the domain given in
enum-context is appended. This causes not much changes
to existing ENUM-clients, some of them already allow
a different apex from e164.arpa to be used or query two 
different trees subsequently.

If no enum-context is given, the ENUMservice "enum" works
as defined in TS 102 172 for e164.arpa

The advantage of this proposal is: minimum change
to the user enum clients and all solutions for
variable length number plans and DDI work as usual.

For the carrier part a new Enumservice "carrier"
is proposed which works in exactly the same way with
a "tel:" and in this case with a mandatory enum-context
parameter.

Using the "tel: URI in this context provides an
additional bonus: the "tel:" URI may be used with
additional parameters, e.g. the ones defined
in draft-ietf-iptel-tel-np-05, especially ";rn=" and 
";cic=". This would allow carriers also to enter
data for numbers existing on the PSTN only and
providing national routing numbers or Carrier Identification
Codes, if required. Carriers may retrieve e.g a routing
number already in ENUM an save an additional IN-dip on the
PSTN.

User ENUM clients do not need to be able to process NAPTRs
with Enumservice "carrier", they may ignore it.

To implement this solution, an additional measure is necessary:

If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR
cannot be stored in e164.arpa any longer (this is also true
for the non-terminal proposal). So the user MUST move out to
another domain e.g. as proposed to joesenum.com. Since there
is no reason normally for a user in e164.arpa suddenly to 
go and look for an own domain if a carrier decides to opt-in,
there should be a default domain available also under e614.arpa,
where the Registrar or Nameserver provider can move the user
in this case. It is proposed to use user.e164.arpa for this
purpose.

This requires a slight modification in the agreements between
IAB, RIPE and ITU-T insofar that
1. this domain is created
2. the delegation of this domain is always performed in
parallel and according the rules as defined in
the Interim Procedures for the delegation of e164.arpa
3. Any existing delegation in e164.arpa gets an automatic
delegation to the same conditions e.g nameservers as stated
in the original request

If carrier ENUM is implemented within e164.arpa and what the
national specific rules are is a national matter and has
to be added to the existing framework for User ENUM.

Best regards

Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Wed, 22 Jun 2005 07:40:23 -0400

Hi Richard, Richard, folks,
This proposal should work, albeit it will take effort and => time to 
analyse and
get the specifications in place - at least it doesn't directly conflict 
with 3761.

N-Ts are, as you spell out, evil (and the existing specs are, at best, 
complex in
this area).

However... As an alternative:
Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers 
aren't, why
not just have a sub-domain (for example carrier.e164.arpa.) 
specifically for Carriers
to populate and query, and leave the Users where they are?

Basically, if the carriers are looking somewhere else, then ALL of the 
problems go away.

The carriers and their suppliers have much better "connections" to ITU 
(and, arguably, to
the IAB and IETF - see current discussion on WG chair commitments on 
the IETF-general list).
If the agreements need to be changed at all, then the 
carriers/suppliers will have to do
this policy (re-)development work anyway.

I am still waiting for convincing arguments justifying the clearance of 
users from the
space allocated for user ENUM.

So far, we seem to have missed that completely.
all the best,
  Lawrence
On 22 Jun 2005, at 11:50, Stastny Richard wrote:
Dear all,

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Jun 2005 09:25:15 -0400

On Jun 22, 2005, at 04:39, lconroy wrote:
This proposal should work, albeit it will take effort and => time  
to analyse and
get the specifications in place - at least it doesn't directly  
conflict with 3761.

FWIW, I am not nervous (as editor and co-chair of the wg) to update  
3761 based on this discussion as well as the excellent document that  
already talk about things that are unclear in 3761.

So, please ignore "unclear" issues in 3761 when discussing.
Concentrate on "architecture".
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Wed, 22 Jun 2005 10:00:34 -0400

Hi Patrik, folks,
  Thanks for the kind words - Fujiwara-san and I will at least up-issue 
the experiences draft
with typo fixes, but it doesn't look like the next version will be able 
to capture the results
of this discussion yet.

Re. update to 3761:
RFC3761 doesn't stand alone. I fear that we *may* need to update 3402 
(and definitely should
update 3403). For example, 3403 section 4.1 has text in the description 
of the REGEXP field
that is (at least), "not transparent".
For DDDS Applications like ENUM/E2U that generate URIs, it does not 
help - is this field used
for a domain name or for a URI (and how do you tell)?
That particular section needs to be clear as clients NEED to know what 
is allowed
and what is not (and how to interpret the field contents).

This is, IMHO, an architectural rather than just a syntax issue.
A "DDDS/ENUM - The Missing Manual" book is definitely needed.
all the best,
  Lawrence
On 22 Jun 2005, at 14:24, Patrik Fältström wrote:
On Jun 22, 2005, at 04:39, lconroy wrote:
This proposal should work, albeit it will take effort and => time to 
analyse and
get the specifications in place - at least it doesn't directly 
conflict with 3761.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Jun 2005 15:21:08 -0400

On Jun 22, 2005, at 07:00, lconroy wrote:

Re. update to 3761:
RFC3761 doesn't stand alone. I fear that we *may* need to update  
3402 (and definitely should
update 3403). For example, 3403 section 4.1 has text in the  
description of the REGEXP field
that is (at least), "not transparent".
For DDDS Applications like ENUM/E2U that generate URIs, it does not  
help - is this field used
for a domain name or for a URI (and how do you tell)?
That particular section needs to be clear as clients NEED to know  
what is allowed
and what is not (and how to interpret the field contents).

Point taken.
   paf

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Jun 2005 09:57:19 -0400

On Jun 22, 2005, at 11:50, Stastny Richard wrote:
1) Should (user) ENUM and Infrastructure (Carrier) ENUM
implementations be mixed within e.164.arpa?
Probably not though it depends on your definitions of "mixed" and 
"Carrier ENUM" and "User ENUM".

2) If yes, how should this be done technically?
Split DNS. Though I can hear Rich Shockey screaming "No!" as I type 
this... :-)

This discussion seems to be doing around in circles and never gets 
anywhere. It also seems to get hung up about the choice of domain name, 
which is beside the point quite frankly. The focus should be on 
requirements and name spaces IMO, not the domain name. Once the 
requirements are clear, the proper DNS architecture will suggest 
itself.
And after that's clear, then it's time to consider what the domain name 
should be.

Let's try to refocus the discussion. User ENUM is inherently an opt-in 
process. The user of a number gets the delegation and populates it with 
whatever they want. Carrier or Infrastructure ENUM is not opt-in as a 
telco will want to provision that for all the numbers they provide 
service for. Consent by the users of those numbers will not be 
required. To all intents and purposes this means Infrastructure ENUM 
can't be in the public DNS. Carriers wouldn't want that anyway since 
this could disclose data they'd prefer to keep secret: location of 
their border gateways, internal network topology, which numbers are in 
use or have been ported, where and how they interconnect with other 
carriers, etc, etc.

So a telco implementing Infrastructure ENUM wouldn't want to use the 
public User ENUM infrastructure. Besides, they won't want that for 
operational reasons. They would not be in control of the public 
infrastructure:  placement and performance of DNS servers, choice of 
hardware and DNS software, monitoring, (D)DoS protection, choice of TTL 
values, propagation of updates, support, etc, etc. It's very unlikely 
any telco would choose to depend on anyone else's infrastructure for 
their most critical network operations: routing phone calls. This means 
that a telco will almost certainly operate their own Carrier ENUM 
infrastructure according to their own operational requirements. Notice 
I've not yet said anything about the domain name that they'd use for 
Infrastructure ENUM.

Therefore each telco will want to set up and run their own Carrier ENUM 
infrastructure according to their own rules and populate that with 
whatever they want. Which is fine. This infrastructure probably 
shouldn't be visible to the public internet anyway. The question is 
then which domain name is used. Well, the first thing to agree is that 
there should be exactly one domain name for Infrastructure/Carrier 
ENUM. This means that there's a common standard that can be followed by 
telcos, vendors, developers and solution suppliers. The same domain 
name will work inside every telco's network. Secondly, it makes it a 
whole lot easier to merge or split these name spaces whenever telcos 
merge their operations or divest something. [If say Verizon and BT 
merge, combining their two private Infrastructure ENUM trees would be 
far simpler if they both use enum.foo (say) instead of one using 
something like enum.us and the other using e164.bt.net.] So the telcos 
need to agree a standard or a convention for the domain name that 
anchors these name spaces.

Now what should be the name of the zone apex that would be at the top 
of this forest of trees, one tree per telco? IMO this should be 
e164.arpa. That's the IETF standard for mapping E.164 numbers to domain 
names after all. So we now have N+1 name spaces for this domain. 
There's the public one on the internet. And there's a private one 
operated and controlled by each telco for its own internal purposes.

Why choose e164.arpa? Well the chances are that the appications used on 
the public internet are very likely to be very similar or identical to 
those used by telcos inside their own networks. On the internet, end 
users are likely to publish details of which SIP server to use to 
terminate VoIP traffic for their telephone number. Unless I've missed 
something, a telco is likely (amongst other things) to use 
Infrastructure ENUM to figure out which SIP server to use for 
terminating VoIP traffic for a given telephone number. So it makes 
sense to be able to use the same software in both places. Though 
obviously, telcos will prefer "carrier class" software from their 
approved suppliers rather than an open source SIP server that has no 
support. The only real difference is that inside the telco's network, 
resolvers are configured to query internal name servers that know about 
the internal DNS infrastructure for e164.arpa instead of the public 
one.

Now telcos could probably share a single, private tree for 
Infrastructure ENUM. This would be a lot cleaner, more efficient and 
very much cheaper to operate. However I think this is an unrealistic 
goal. It would be very difficult to get all the telcos to agree a 
common set of requirements, far less figure out a way to pay for the 
setup and operation of that shared infrastructure.

---

From: Marian Durkovic <[email-masked]>
Date: Thu, 23 Jun 2005 10:15:30 -0400

> operated and controlled by each telco for its own internal purposes.

Jim,

  if the internal DNS is using the same domain as public DNS, the end result
is, that public DNS is invisible. How would a telco route calls to e.g. 
ENUM-only ranges in different countries, when it has overlayed the
public e164.arpa with its private data?

  Supporting queries into other domains is no problem, require typically
one line of configuration.

	With kind regards,

		M. 

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------