Subject: [Enum] Benefits of "Carrier" / "User" enumservices

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Wed, 15 Jun 2005 12:44:14 -0400

Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed
it with colleagues, I have some concerns about its drawbacks and am
struggling to see what benefits it offers.

It may be that I've missed a key point or mis-understood something so I
would be grateful if someone can assist with explanation and
clarification.

The first concern is that if this registration and accompanying data is
introduced, its implications about how DNS data is structured breaks
existing enum resolvers. For example, when a resolver queries the
e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all
the NAPTR records matching this number and then looks for a match on the
enumservices "E2U" and "SIP". This matching will fail as only NAPTR
records with "Carrier" or "User" are present and the call fails. To
introduce these enumservices successfully requires all existing enum
resolvers to be re-implemented. The resolver has to first look for a
match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then
look for a match on "E2U" and "SIP".

The second concern is how the "Carrier" enumservice meets the needs of
telcos. As I understand it, the major driver for introduction of Carrier
enum is to address privacy concerns. Telcos don't want their enum data
available for inspection and attack by everyone on the Internet and the
carrier enum concept addresses this by making the data inaccessible
except to authorised queries. However, the use of the Carrier
enumservice only shifts the DNS query to a different DNS domain on the
Internet and makes no difference to the privacy or access privileges.
It's not clear to me what the benefit of "Carrier" enumservice is for
data privacy compared to the case of not having it. 

Kim Fullbrook

=====================================================
This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
=====================================================

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

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 15 Jun 2005 13:05:52 -0400

Kim:

I'm not sure I agree with your assessment of what gets broken. My belief
is that clients compliant with RFC 3761 should process non-terminal
NAPTRs. The matching on a service within E2U such as SIP should occur on
terminal NAPTRs. There will be a need to support the new enum services
of "user" and "carrier".

As to the benefits to carriers, our motivator is NOT primarily privacy,
it's effective interconnection. User ENUM in many countries requires end
user opt-in and may give the end user the right to select the Tier 2
that hosts the terminal NAPTR records. These constraints are problematic
for interconnection which requires registration for all served numbers
and carrier control of Tier 2 to ensure reliability.

Although the I-D did not go into it, there are techniques for
controlling access to actual routing data or offering up different IP
points of interface (e.g. different Session Border Controller point) to
different carriers. How open interconnection will be to non-carrier
parties is a business decision for individual carriers but we believe
the proposed implementation can support whatever is decided.

Some kind of ENUM will be used for interconnection as voice moves to
being an application on IP networks. Our preference is that this
implementation be synergistic with end user ENUM. 

Penn Pfautz

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Fullbrook Kim (UK)
Sent: Wednesday, June 15, 2005 12:44 PM
To: enum at ietf.org
Subject: [Enum] Benefits of "Carrier" / "User" enumservices

Kim Fullbrook

=====================================================
This electronic message contains information from O2 which may be
privileged or confidential. The information is intended to be for the
use of the individual(s) or entity named above. If you are not the
intended recipient be aware that any disclosure, copying distribution or
use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone
or email (to the numbers or address above) immediately.
=====================================================

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 15 Jun 2005 14:19:33 -0400

I concur with Penn's entire response, and specifically on the reasoning
/ drive behind the use of so-called carrier ENUM.  

To add another data point...  As a carrier, our interest is in using
ENUM-related specifications and capitalizing on / co-existing with
end-user, public ENUM.  Part of that means easy, open interconnection,
of which public ENUM can play a very important role.  Access is only a
concern for actual media & signaling traffic, and access priviliges can
be addressed in SIP proxies, media gateways, softswitches, session
border controllers, etc. depending upon a particular carrier's
architecture and their business model.  We are not too concerned with
other carriers knowing what numbers we have for two reasons: (1) that is
the entire objective - to share such information so that we can
interconnect and (2) this information is already available to other
carriers through shared PSTN-oriented routing databases, such as the
NPAC (LNP) in North America.

Jason Livingood  

> The second concern is how the "Carrier" enumservice meets the 
> needs of telcos. As I understand it, the major driver for 
> introduction of Carrier enum is to address privacy concerns. 
> Telcos don't want their enum data available for inspection 
> and attack by everyone on the Internet and the carrier enum 
> concept addresses this by making the data inaccessible except 
> to authorised queries. However, the use of the Carrier 
> enumservice only shifts the DNS query to a different DNS 
> domain on the Internet and makes no difference to the privacy 
> or access privileges.
> It's not clear to me what the benefit of "Carrier" 
> enumservice is for data privacy compared to the case of not 
> having it.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 15 Jun 2005 15:05:25 -0400

Penn,
 
a minor correction:
you are correct that according to RFC 3761 a client should be able
to process non-terminal NAPTRs as defined, which means NAPTRs
having only "E2U" in the enumservice field, without any additional 
enumservices defined. The original intention was that you query
the domain given for NAPTRs and THEN decide which enumservice
to use.
 
The definitions of the enumservices "user" and "carrier" you draft
is NOT according to the template in RFC 3761, because you MUST define
the URIs valid for this enumservice (and not N/A), as Lawrence already
pointed out.
 
In addition, even if clients have implemented the capability to use
non-terminal NAPTRs, up to now they need not to be able to understand
and interpret any enumservice defined (only they ones they can handle)
 
With your proposal any ENUM-client not understanding the enumservices
"user" and "carrier" will not be able to retreive any enumservice at all.
 
This is of course also true for the proposal I made using for this purpose
terminal NAPTRs with enumservice "enum:tel" and carrier:tel",
using the phone-context in tel: as apex for the new tree.
but this proposal has other advantages.

But one should be careful in saying any client in the MUST support this
because this is already defined in RFC 3761.
 
regards
Richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO
Gesendet: Mi 15.06.2005 19:05
An: Fullbrook Kim (UK); enum at ietf.org
Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices

Kim:

Penn Pfautz

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

Kim Fullbrook

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Wed, 15 Jun 2005 15:12:50 -0400

Richard.
Fair enough. I confess to some uncertainty re how to populate the URI
part of the template for non-terminals. I toyed with something like "all
URI schemes registered under any other enumservice." Would that have
been better? 

Penn

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
Sent: Wednesday, June 15, 2005 3:08 PM
To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices

Penn,
 
a minor correction:

 
With your proposal any ENUM-client not understanding the enumservices
"user" and "carrier" will not be able to retreive any enumservice at
all.
 
This is of course also true for the proposal I made using for this
purpose
terminal NAPTRs with enumservice "enum:tel" and carrier:tel",
using the phone-context in tel: as apex for the new tree.
but this proposal has other advantages.

regards
Richard

Kim:

Penn Pfautz

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

Kim Fullbrook

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 15 Jun 2005 15:29:01 -0400

Penn,
 
I am not the one to answer you THIS question ;-)
but IMHO we have here a catch 22
because in the replacement field there cannot be 
an URI at all, the enumservice template is 
only valid for flag 'u' and not for non-terminal NAPTRs
 
regards
Richard

Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com]
Gesendet: Mi 15.06.2005 21:12
An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org
Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices

Richard.

Penn

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at]
Sent: Wednesday, June 15, 2005 3:08 PM
To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices

Penn,

a minor correction:

regards
Richard

Kim:

Penn Pfautz

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

Kim Fullbrook

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 15 Jun 2005 16:15:30 -0400

Steve,
 
This is one possibility and should be done anyway, but this will take time
 
The other (easier and faster) possibility is to stick with terminal NAPTRs
if this also solves your problem
 
regards
Richard

Von: Lind, Steven D, ALABS [mailto:sdlind at att.com]
Gesendet: Mi 15.06.2005 22:08
An: Stastny Richard; Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices

It seems to that if this is the case, the template does not cover all the cases described in RFC 3761. Do we need a second template for non-terminal NAPTRs or change the existing template (and associated instructions) to incorporate both types of NAPTRs.

Steve Lind

--------------------------------------------------------------------------------
Steven D. Lind                                Tel: 973-236-6787
180 Park Avenue                             Fax: 360-343-2875
Room A201                                    sdlind at att.com
Florham Park, NJ 07932
--------------------------------------------------------------------------------

> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
> Stastny Richard
> Sent: Wednesday, June 15, 2005 3:32 PM