Subject: [Enum] Carrier ENUM alternatives

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 22 Jun 2005 09:01:26 -0400

Richard:
Thanks for nicely laying out the alternatives and their implications. I
want to stress to Lawrence that the non-terminal NAPTR proposal was not
about trying to push out users but trying to bring *in* carriers. We are
moving to IP interconnection and ENUM technology is the right way to do
it, so the question is not whether but where/how. 
We (the I-D authors) feel it's preferable to try to do this together
with user ENUM, not only to avoid  restart at square 1, but also to jump
start the infrastructure. Given the meager success of public user ENUM
so far, one might think that would be seen in a positive light. The
separate domain approach remains an alternative and, if necessary, I
expect we'll go down that path. But if we do there'll be much less
incentive for carriers to devote resources to the support of user ENUM.
I sense ETSI has already nearly thrown in the towel.

Not giving up on non-Terminals but thinking about the terminal NAPTR
proposal....
Penn

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Stastny Richard
Sent: Wednesday, June 22, 2005 7:56 AM
To: lconroy
Cc: enum at ietf.org; Richard Shockey
Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful

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

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