Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

From: "Stastny Richard" <[email-masked]>
Date: Wed, 22 Jun 2005 11:31:32 -0400

As I said I the other reply I did originally not mean this
but this is an valid  option.
 
To know the apprx 200 Country codes is a non-starter for
user ENUM and clients, but not for carriers, they have to know this anyway
(they currently have to know nuch more)
 
You just have to maintain the table provided regularly at
http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html
 
Richard

________________________________

Von: Michael StJohns [mailto:mstjohns at mindspring.com]
Gesendet: Mi 22.06.2005 17:18
An: Stastny Richard; lconroy
Cc: enum at ietf.org; Richard Shockey
Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful

One other point - assuming I understand what you want (- e.g.
carrier.1.e164.arpa for CC 1).  I believe this will require the end
resolver to know where the country code ends for all given country
codes.  And that makes this option pretty much a non-starter.

At 07:56 AM 6/22/2005, Stastny Richard wrote:

>c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T
>only on the side, but definitely the national regulators.
>The international policy framework may be taken basically as is, but
>national policy needs to be amended. So the time taken is a national
>matter, but it may be easier and faster to set-up (less involved
>parties)
>The other benefit: National regulators may be forced by the carriers
>to opt-in to e164.arpa, which may be of benefit also for User ENUM.
>-> Continue where we are.

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

---

From: Michael Haberler <[email-masked]>
Date: Wed, 22 Jun 2005 15:14:13 -0400

At 17:31 22.06.2005, Stastny Richard wrote:
As I said I the other reply I did originally not mean this
but this is an valid  option.
To know the apprx 200 Country codes is a non-starter for
Actually, this is a "starter".
The country code and its length can be trivially extracted from a given number.
See the code here: http://mah.priv.at/enum/cc_code.c .
As long as ITU sticks to its allocation rules, that piece of code does the 
job fine.

As a safety net for the non-believers, an appropriate "marker" record could 
be inserted at the cc boundary and cached at the client.

-Michael

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Wed, 22 Jun 2005 15:19:45 -0400

Indeed.  Typically we have to maintain data at 7-9 digits (inc country code), depending on the destination.

However, approaching this as a potential customer of infrastructure-ENUM (being a competitive carrier in some countries and the "incumbent" in many more), the approach of carrier.c.c.e164.arpa doesn't overcome the concerns that I have about sharing the top level domain.

The world has moved on, and a series of delegations have already been made in the .e164.arpa domain.  Typically, for the delegations already made, telcos have played little or no part...it has not been seen as part of their core telephony business, though potentially of interest for the ISP side of the house.  For example, a series of countries where Cable & Wirelss is the incumbent have made such delegations, and that's not something that's overly concerned us so long as the companies concerned are known to be legitimate.   

Now, if infrastructure-ENUM is going to be used for routeing of the public telephone service, the landscape dramatically changes.  Certainly, where carriers in a given country are entering their routeing data, they would wish to give consideration to whether the administration/operation of the Tier-1 registry for infrastructure-ENUM in their country should be an entity jointly owned by the stakeholders (ie the carriers).  I'd go as far as to predict that many carriers would simply not load their data into a Tier-1 over which they have no direct or indirect control.  Without data an infrastructure-ENUM would be of limited use...

Unfortunately, in a series of locations (user) ENUM has already moved on sufficiently far that such considerations would be too late if an attempt was made to shoe-horn user- and infrastructure- ENUM into the same domain : the Tier-1 has already or will be imminently awarded.

Now, following carrier.c.c.e164.arpa logic, the carrier queries would still go via the (already selected) Tier-1, albeit only for a single entry rather than one per number.  If it had to be in .e164.arpa, the other way around (c.c.carrier.e164.arpa) would seem to be the way to avoid the issues I raise.

Regards

Paul  

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
Stastny Richard
Sent: Wednesday, June 22, 2005 4:31 PM
To: Michael StJohns; lconroy
Cc: enum at ietf.org; Richard Shockey
Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

 
 
Richard

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service,  visit http://www.cw.com/uk/emailprotection/ 
 
The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 22 Jun 2005 15:41:00 -0400

Hi Paul,
 
I see your point, but I think you are a bit overoptimistic on the capability of
the carriers to agree on an entity "jointly owned by the stakeholders" ;-)
Take UK (or Austria) as an example, where the "stakeholders" where
not able to agree on a j"ointly owned" datebase for NP, even if they
loose money with this decision.
 
On the other hand,  the current Tier 1 Registries are in most counties
selected by the Regulator as the domain name holder and also in 
most cases the ccTLDs or other companier within this business. 
These enties know how to do their jobs
and a lot of business of the telcos is dependant on their operations
anyway.
 
Richard

Von: enum-bounces at ietf.org im Auftrag von Rosbotham, Paul
Gesendet: Mi 22.06.2005 21:19
An: enum at ietf.org
Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful

Regards

Paul 

-----Original Message-----

Richard

---

From: "Lind, Steven D, ALABS" <[email-masked]>
Date: Wed, 22 Jun 2005 15:59:34 -0400

This has been a very interesting discussion of various technical options, but they may not fit everyone's' needs as we found out with the pfautz-lind I-D. One needs to be cognizant of the fact that in the US, we are in a regulatory environment where competition and end-user choice is very important. In the ENUM sense, that means for end-user ENUM, end-users should have their choice of Registrar and DNS provider to host their terminal NAPTR records. Putting those records in the Tier 1 has been, at least to date, not an option. And trying to accommodate the needs of carriers without tromping on the needs (or choices) of end users led us in a specific direction (i.e., the pfautz-lind I-D). 

The other factor in that choice of pathways was the desire for whatever was doing the ENUM query to get back as many of the records, user & carrier, as possible, and to apply whatever business model made sense for that entity to select the appropriate record to complete the communication. Some of your proposed alternatives, while not making such a direction impossible, will make looking for both sets of records less attractive.

Steve Lind

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Patrik Fältström
Sent: Wednesday, June 22, 2005 3:46 PM
To: Stastny Richard
Cc: enum at ietf.org; lconroy; Richard Shockey
Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

On Jun 22, 2005, at 07:41, Stastny Richard wrote:

> c1: using non-terminals
> c2. using terminal NAPTRs
> both options having these NAPTRs side-by-side
> in tier 1.
>
> c3: moving the carriers to  e.g 1.2.3.4.carrier.c.c.e164.arpa
> I considered this option as ugly and requiering special clients,
> to derieve the domain to query from the E.164 number and
> knowing the CC structure, but as Lawrence pointed out,
> carriers should know this anyway ;-)
>

Carriers, yes, but think of the poor stupid device that want to use  
the information the carriers have put in dns? I.e. only carriers  
might store things there, everyone might do lookups.

    paf

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Jun 2005 03:14:31 -0400

Steve,
> 
> This has been a very interesting discussion of various technical options,
> but they may not fit everyone's' needs as we found out with the pfautz-
> lind I-D. 

Could you please elaborate which of the discussed options do
NOT fit "everyone's" needs?

> One needs to be cognizant of the fact that in the US, we are in
> a regulatory environment where competition and end-user choice is very
> important. 

Agreed. But I as an end-user want to have the choice to STAY in e164.arpa
And to not want to be thrown out because a carrier decided to opt-in.

> In the ENUM sense, that means for end-user ENUM, end-users
> should have their choice of Registrar and DNS provider to host their
> terminal NAPTR records. 

Exactly, and my choice is e.g. 1.1.2.2.0.3.0.2.7.3.4.e164.arpa, where I
put my sip URI

> Putting those records in the Tier 1 has been, at
> least to date, not an option. 

Nobody proposed to put e.g. a NAPTR pointing to a SIP URI in Tier 1. Maybe
you did not completely understood the options.

> And trying to accommodate the needs of
> carriers without tromping on the needs (or choices) of end users led us in
> a specific direction (i.e., the pfautz-lind I-D).

But with your proposal you are tromping all existing ENUM implementations
worldwide. I understand an US centric view, but you should consider that
CC+1 is not even delegated yet in e164.arpa, whereas over 30 countries
already are. They all would have to change.

> 
> The other factor in that choice of pathways was the desire for whatever
> was doing the ENUM query to get back as many of the records, user &
> carrier, as possible, and to apply whatever business model made sense for
> that entity to select the appropriate record to complete the
> communication. 

Again, please elaborate which of the other options is not allowing this

> Some of your proposed alternatives, while not making such a
> direction impossible, will make looking for both sets of records less
> attractive.

Huh? Please elaborate why? Only in the carrier.c.c.164.arpa proposal, where
you need two queries. In your proposal to get the data of all alternatives
you need at least 4 queries.

To be precise, in this regard your proposal is the worst.

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

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Thu, 23 Jun 2005 03:43:27 -0400

Richard,

just one question: 
in 1.2.3.4.carrier.cc.e164.arpa, the field named "carrier" is NOT assumed to be replaced by the "name of the operator servicing that very number". It is only used to separate the carrier part of the tree.
Otherwise it would impact the way ported numbers are handled

greetings

HannsJuergen

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard
Sent: Wednesday, June 22, 2005 4:41 PM
To: Patrik Fältström
Cc: enum at ietf.org; lconroy; Richard Shockey
Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

Thank you Patrik for this clarification.
 
I also agree that option c is preferable
 
During the discussion a third alternative showed up:
 
c1: using non-terminals

The advantage of this solution would be that User ENUM
in e164.arpa remains completely untouched. User Clients
would normally never see these domains
 
The second advantage is that in case c1 and c2 ALWAYS
two or three queries are necessary, in case c3 only one,
both for user and carrier.
 
The "ugly part" remains with the carriers, and they may deserve this
anyway ;-)
 
Richard

Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: Mi 22.06.2005 15:23
An: Stastny Richard
Cc: lconroy; enum at ietf.org; Richard Shockey
Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

On Jun 22, 2005, at 04:56, Stastny Richard wrote:

> The following options exists:
> Put the Carriers in:
> a. e164carrier.arpa - this requires only the IAB and does not involve
> ITU-T
> BUT requires a policy framework to be set up by whom? This may take
> some time even to create a body. -> Restart at square -1

Having two domains in the DNS not technically bound to each other 
(i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions 
regarding policy for who runs the (two) domains. Having them 
synchronized in any way will be a nightmare, and, it forces the local 
regulative bodies that already have had headache over "who will run 
cc.e164.arpa" to wake up again.

> b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the
> national regulators.
> BUT involves for policy mainly the ITU-T. So the body is known, but
> since even the interim procedures are not places in a Rec. yet ...
> -> restart at square 1

See earlier bullet. Similar problems, as you point out.

> matter, but it may be easier and faster to set-up (less involved

Correct. The policy have to be adjusted in some cases, but the policy 
work is, I claim, not at all as heavy as the previous suggestions.

> Conclusion: option c may not be the optimal solution, but it will
> be definitely the fastest for the carriers and also be of some
> benefit for User ENUM.

I agree.

    paf

> Additional remark:
> Other trees may and will co-exist, but any tree in e164.arpa may
> serve as a glue. GSMA operators just need to put a pointer in to
> ;enum-context=e164.enum.net
>
> Regards
> Richard
>
>
>
> Richard Stastny
> OeFEG
> tel:+43 664 420 4100
> enum:+43 780 203 211
> callto://fordprefect
>> From: lconroy [mailto:lconroy at insensate.co.uk]
>> Sent: Wednesday, June 22, 2005 1:40 PM
>> To: Stastny Richard
>> Cc: 'enum at ietf.org' ENUM; Richard Shockey
>> 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,
>>>
>>> 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
>> ---------------------------------------
>> lawrence conroy    |tel:+44-1794-833666
>>
>
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Jun 2005 04:10:20 -0400

HansJürgen,

in the 1.2.3.4.carrier.cc.e164.arpa option, no additional
Enumservices etc. are needed, this is plain ENUM.

In carrier.cc.e164.arpa domain (the carrier Tier 1) NS records 
point to tier 2 domains e.g. 1.2.3.4.carrier.cc.e164.arpa,
containing "normal" NAPTR records, e.g. with Enumservice "sip". 
The only "ugly" issue here
is that the carriers will need to know the country codes to
find the carrier Tier 1 e.g. carrier.9.4.e164.arpa and
the Tier 1 label "carrier" has to be agreed upon.

The doubts by some netheads that the carriers may not be able
to find out the country codes sheds some light on the opinion
some netheads have about the intelligence of the bellheads ;-)

Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect

> From: Schwarzbauer Hanns Juergen
> [mailto:hannsjuergen.schwarzbauer at siemens.com]
> Sent: Thursday, June 23, 2005 9:43 AM
> To: Stastny Richard; Patrik Fältström
> Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful
> 
> Richard,
> 
> just one question:
> in 1.2.3.4.carrier.cc.e164.arpa, the field named "carrier" is NOT assumed
> to be replaced by the "name of the operator servicing that very number".
> It is only used to separate the carrier part of the tree.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 23 Jun 2005 10:43:35 -0400

Please keep the reachability and ability to discover an address
completely separate.  They are absolutely orthogonal issues.  There are
many reasons (out of radio range, not registered, feature blocking) that
someone might not be reachable.  I could have a fight with my girlfriend
and be "unreachable" today, make up with her and be "reachable"
tomorrow.  That has nothing to do with whether I can translate an E.164
number to a SIP address, be it direct or some proxy.

Mike

> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Jim Reid
> Sent: Thursday, June 23, 2005 5:19 AM
> To: Michael Haberler
> Cc: enum at ietf.org; Stastny Richard; lconroy; Patrik Faltstrom 
> (pfaltstr); Richard Shockey
> On Jun 23, 2005, at 08:01, Michael Haberler wrote:
> > "publicly available" doesnt necessarily translate into "openly 
> > reachable for everybody"
> 
> Indeed. The DNS is just a way to make information publicly available. 
> It makes no judgements about the content that's stored there. 
> That said, advertising information in the public DNS about 
> end-points that are not openly reachable is pointless.
> 
> > or is "openly reachable" a requirement posed on all URI's under 
> > e164.arpa ? It might be an implicit assumption but I havent 
> seen such 
> > a requirement
> 
> No. And I'm not sure this is an implicit assumption either. 
> Perhaps it should be an explicit assumption. Maybe there 
> should be an ENUM WG I-D along the lines of Philip Hazel's 
> draft-ietf-dnsop-dontpublish-unreachable-03.txt which was 
> about IP addresses that should never appear in the public 
> DNS. The ENUM version would of course be concerned with 
> unreachable URIs. Or URI end points that have access control 
> filters in front of them. Technically, these are generally 
> reachable: they're just not accessible to everyone.
> 
>