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

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

Lawrence said:
> 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?

This is basically the TISPAN WG4 proposal and my issue 1

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

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

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.

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.

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
http://voipandenum.blogspot.com

> -----Original Message-----
> 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
> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful
> 
> 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
> > http://voipandenum.blogspot.com
> >
> >
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> >
> >
> ---------------------------------------
> lawrence conroy    |tel:+44-1794-833666

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

---

From: lconroy <[email-masked]>
Date: Wed, 22 Jun 2005 08:24:14 -0400

Hi Folks,
 for precision/clarity, Kim has registered:
e164enum.net,
    NOT
e164.enum.net.
Thus it would be ;enum-context=e164enum.net.
atb, L
On 22 Jun 2005, at 12:56, Stastny Richard wrote:
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
---------------------------------------
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:23:54 -0400

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.
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)
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.

I agree.
   paf

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

-----Original Message-----
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
Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful
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).

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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 22 Jun 2005 11:19:19 -0400

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:

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 22 Jun 2005 11:27:32 -0400

> codes.  And that makes this option pretty much a non-starter.

Not so.

* It's only an issue for carriers, who can maintain a table.

* It's not much data to maintain, since there's a fixed set of 1- and
2-digit codes and all others are 3 digit.

* Given that, it's not actually impractical to always do it at the 3-digit
level and have the 1- and 2-digit countries have multiple entries.

* Or, if you don't have the lengths stored, simply try each length in turn
until it works, so for +234 you look up:

    carrier.2.e164.arpa
    carrier.3.2.e164.arpa
    carrier.4.3.2.e164.arpa

in turn.

* Or even use the DNS to store the length information so that relevant
(specialised) clients can look it up.

In summary, it's not a big deal for those doing carrier enum. Though I
would prefer using carrier.e164.arpa anyway.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Jim Reid <[email-masked]>
Date: Wed, 22 Jun 2005 12:29:21 -0400

On Jun 22, 2005, at 16:27, Clive D.W. Feather wrote:
Michael StJohns said:
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.
Not so.
* It's only an issue for carriers, who can maintain a table.
This assumes carriers will always keep this table up to date, which is 
debatable. The general lack of DNS clue in the world suggests that 
maintaining this hypothetical table is unlikely to happen at every 
carrier. In fact I believe some carriers are not particularly diligent 
about reprogramming their SS7 switches whenever a new "country code" is 
announced in the ITU Operational Bulletin. If that is the case, then 
there's no hope of carriers maintaining this table and preserving a 
consistent name space in the DNS.

* It's not much data to maintain, since there's a fixed set of 1- and
2-digit codes and all others are 3 digit.
I'm not sure that's true -- prefixes for satellite operators and the 
like -- and anyway it presumes the current E.164 numbering scheme isn't 
ever going to change. It's highly unlikely the numbering scheme will 
change, but if it did...

* Given that, it's not actually impractical to always do it at the 
3-digit
level and have the 1- and 2-digit countries have multiple entries.
I don't understand this.
And what would you do for NANP where a carrier wants to have a discrete 
entry for an area code under +1 that happened to be for one of the 
Carribean states? Or if one of those states gets an extra 3 digit area 
code?

* Or, if you don't have the lengths stored, simply try each length in 
turn
until it works, so for +234 you look up:

    carrier.2.e164.arpa
    carrier.3.2.e164.arpa
    carrier.4.3.2.e164.arpa
in turn.
This is a remarkably bad idea. Playing the game of "hunt the domain 
name" by walking up or down the tree is asking for trouble. It  will 
create lots of operational problems, like unpredictable results. It 
will have serious performance impact too. For example, suppose an 
application  wants to dial 1234567890. A lookup of carrier.1.e164.arpa 
returns NXDOMAIN. That could mean 1.e164.arpa does not exist, so the 
application would try carrier.2.1.e164.arpa and so on, getting an 
NXDOMAIN every time all the way to 
carrier.0.9.8.7.6.5.4.3.2.1.e164.arpa before giving up and reporting a 
failure. Bad. Bad. Bad.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 22 Jun 2005 14:51:17 -0400

At 11:27 AM 6/22/2005, Clive D.W. Feather wrote:
It's only an issue for carriers, who can maintain a table.
You're much more optimistic than I am in that you think you know who will 
actually end up needing to use this data.  For example, will the 
non-carrier billing people need access?  Will the emergency services folks 
(911, 999) need access?  Etc.  Given the number of people who have glommed 
onto the DNS as their solution to some pretty weird problems you should 
expect a lot of glomming onto ENUM of both the carrier and user sort going 
forward.

* It's not much data to maintain, since there's a fixed set of 1- and
2-digit codes and all others are 3 digit.
The key word here is "fixed".  NOTHING is fixed in the digital world - it 
just looks like it from a pov of only a few years wide.  Let's say that in 
10 years the whole CC mess goes by the wayside because it doesn't fit well 
with VOIP - but that it can't go by the wayside because the design has 
locked in certain assumptions on how the data is formatted.

The argument that you can go out and get the new mappings is interesting, 
but without merit unless those mappings are maintained within the DNS 
itself and the updates are part of the DNS protocol.  E.g. how do you 
ensure that you've contacted everyone that needs to know about a 
change?  How do you coordinate a change?

* Given that, it's not actually impractical to always do it at the 3-digit
level and have the 1- and 2-digit countries have multiple entries.
Hmm... you mean carrier.0.3.1.e164.arpa to represent area codes 
300-309?   I don't think that's practical and I'm pretty sure that any 
scheme for +1 that doesn't break delegation points at the CC and area code 
boundaries won't fly.