Subject: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt"

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Jul 2004 11:38:52 -0400

Thanks to Penn and 
Steve for submitting this draft!  It appears to present a workable 
technical solution to the discussions we've been having on infrastructure vs. 
end user ENUM (putting privacy concerns aside for a moment).
<SPAN 
class=825172714-22072004> 
I have minor 
comments / suggestions that may make this draft more usable in practice, and 
more acceptable to a wider audience.  This involves 
a modification of the class of service acronyms.  

<SPAN 
class=825172714-22072004> 
The draft proposes 
two class of service acronyms:
1.  E2U - ENUM 
to URI, for End User records.
2.  E2C - ENUM 
to Carrier, for Carrier or Service Provider records
<SPAN 
class=825172714-22072004> 
Which look like 
this, as cited in the draft:
    
$Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. 
       IN NAPTR 100 50 "" "E2U"   "" 
9.0.3.5.7.6.8.7.9.4.1.joesenum.com        IN 
NAPTR 100 50 "" "E2C"   "" 9.0.3.5.7.6.8.7.9.4.1.telco.net 

<SPAN 
class=825172714-22072004> 
I submit that in the 
practice of manually provisioning records in the DNS, in troubleshooting, or in 
general human use and reading of DNS records or query results, that "E2U" and 
"E2C" are simply to similar to one another visually.  I think that in 
practice this could cause unnecessary difficulty and confusion.  I would 
recommend that a different acronym be chosen for infrastructure uses that is 
unmistakably different from "E2U."  This would pay heed to the human 
factors that will be present when dealing with a large number of these 
records day in and day out.
<SPAN 
class=825172714-22072004> 
The second concern 
is around the word "Carrier" and therefore the "C" portion of the class of 
service acronym.  I believe that carrier is a rather limited 
description of the entities which may have networks and services associated 
with this class of service.  I would suggest instead something focused on 
"service providers."
<SPAN 
class=825172714-22072004> 
For these two 
reasons, I think that the draft should modify the seconds acronym from "E2C" to 
something else, perhaps "SPR" (Service Provider Record) or "SPU" (Service 
Provider URI).<SPAN 
class=825172714-22072004>
<SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face=Arial 
size=2> 
<SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><SPAN 
class=825172714-22072004>Respectfully submitted, 
<SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><SPAN 
class=825172714-22072004>Jason
<FONT face=Arial 
size=2> 
Jason Livingood
Director - Forward Looking Communication 
Services
Communications Services 
Engineering
Comcast Cable 
Communications
215-981-7813
<FONT face=Arial 
size=2>jason_livingood at cable.comcast.com
 
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Fri, 23 Jul 2004 20:14:25 -0400

A clarification - we need to distinguish between a carrier's internal routing data and
a specification of points of interface.

While carriers might and could decide to put the final route to the end user terminal in the public DNS, they might also just
put in a border element address. This allows others to deliver calls to the carrier for ulimate delivery
to an end user while maintaining some protections. (Indeed such protections may be one of the things
voice carriers -as potentially distinct from underlying ISPs- have to offer as value added - but that's
another story).

And because a carrier could put such border element addresses in ENUM and can put all the numbers in ranges
assigned to them (except ported out numbers), it's not so much of a problem if an unlisted number is there,
because it's not correlated to a specific end user identity. Even numbers that are currently vacant may be there.

But the point of this draft *is* to expose some kind of routing to outside parties. I want them to be able to reach
my customers in the IP plane and I want, in turn, to reach theirs that way. The private possibilties of the protocol
defined in RFC 2916 have been recognized from the start, but If carrier ENUM is something just between
consenting service providers in an  equipment closet, then, it's a whole lot less interesting to me.

Penn

-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com]
Sent: Friday, July 23, 2004 3:09 PM
To: Richard Shockey
Cc: Richard Stastny; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn
L, ALABS
Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" 

>>>>> "Richard" == Richard Shockey <richard at shockey.us> writes:

    Richard> Given that the administrative policies and procedures
    Richard> regarding the various trees of e164.arpa are by IAB/ITU
    Richard> definition nation state matters I continue to find it
    Richard> baffling that service providers would want to put the
    Richard> administrative, policies and procedures surrounding their
    Richard> internal routing data within the grasp of their (NRA's)
    Richard> regulators.

    Richard> What are you all thinking?

I'm with you.

IMO, the trees for User and Infrastructure/Operator ENUM must be
mutually exclusive. They serve different purposes and have mutually
exclusive contraints on subjects like data protection, privacy,
authentication, verification, opt-in/out, regulatory considerations,
etc, etc. For example if I have an unlisted number, it more than
likely shouldn't be in the public (User) ENUM tree. But if my provider
is doing VoIP, my number will need to be in their private Operator
tree so their call routing stuff can find the appropriate SIP gateway
or whatever for my number.

I also find it curiously refreshing that an operator would choose to
expose its customer data and routing info to competitors. Or the
general public. Which this draft seems to be promoting. Maybe I'm
missing something?

---

From: Roger Fearing <[email-masked]>
Date: Fri, 23 Jul 2004 21:34:59 -0400

Ives, Ray,
I think they are beginning to get it...if I am reading them right...
See;
"This allows others to deliver calls to the carrier for ulimate delivery to 
an end user while maintaining some protections. (Indeed such protections 
may be one of the things voice carriers -as potentially distinct from 
underlying ISPs- have to offer as value added - but that's another story)."

Sincerely,
Roger
At 08:04 PM 7/23/04 -0400, Pfautz, Penn L, ALABS wrote:
A clarification - we need to distinguish between a carrier's internal 
routing data and
a specification of points of interface.

While carriers might and could decide to put the final route to the end 
user terminal in the public DNS, they might also just
put in a border element address. This allows others to deliver calls to 
the carrier for ulimate delivery
to an end user while maintaining some protections. (Indeed such 
protections may be one of the things
voice carriers -as potentially distinct from underlying ISPs- have to 
offer as value added - but that's
another story).

And because a carrier could put such border element addresses in ENUM and 
can put all the numbers in ranges
assigned to them (except ported out numbers), it's not so much of a 
problem if an unlisted number is there,
because it's not correlated to a specific end user identity. Even numbers 
that are currently vacant may be there.

But the point of this draft *is* to expose some kind of routing to outside 
parties. I want them to be able to reach
my customers in the IP plane and I want, in turn, to reach theirs that 
way. The private possibilties of the protocol
defined in RFC 2916 have been recognized from the start, but If carrier 
ENUM is something just between
consenting service providers in an  equipment closet, then, it's a whole 
lot less interesting to me.

Penn
-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com]
Sent: Friday, July 23, 2004 3:09 PM
To: Richard Shockey
Cc: Richard Stastny; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn
L, ALABS
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 7/19/04

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 7/19/04
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Sun, 25 Jul 2004 21:31:41 -0400

Richard:
I'd agree that if national regulators choose not authorize a delegation parties can and will look to private listing services, at least in principle. (Although some nations may take a heavier hand even about that).
My hope is that it is not necessary to go down that path - and one of my arguments to those in the ITU concerned about control has been that if  NRAs play dog in the manger they are likely to wind up having no say at all. 

In terms of whether non-carriers can read the carrier path, that remains to be seen. I still prefer a model in which, while carriers may keep internal routing data proprietary, they may make points-of-interconnection accessible to all. 

Penn

-----Original Message-----
From: Richard Shockey [mailto:richard at shockey.us]
Sent: Sunday, July 25, 2004 2:57 PM
To: Pfautz, Penn L, ALABS; Stastny Richard; Livingood, Jason;
enum at ietf.org; Lind, Steven D, ALABS
Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt"

At 04:57 PM 7/23/2004, Pfautz, Penn L, ALABS wrote:

>content-class: urn:content-classes:message
>Content-Type: text/plain;
>         charset="utf-8"
>
>Richard:
>
>The basic problem I'm trying to address is how the use of ENUM 
>for  carrier interconnection can coexist with its use by end users, the 
>latter of which I take as a given based on what has transpired in the IETF 
>and ITU.

Penn I know exactly what you are trying to address but I'm of the personal 
opinion that the two issues are orthogonal and that the use of the 
e164.arpa tree  1. creates an entirely new set of behaviors for CUA 
resolvers that were not originally anticipated 2. binding the two so 
closely to e164.arpa creates many of the same political problems we see in 
"public ENUM" re getting actual delegations from the NRA's and the rules 
NRA will bind to the use of those delegations.

>If end user choice is a possibility, then there are issues with what to do 
>if the end user wishes to register something other than a the carrier info 
>and vice versa.
>I don't believe this always requires two queries, and, in fact, that's 
>what I'm trying to avoid.

Avoidance of two queries would certainly be preferred but the practical 
problems

>An entity quering the proposed combined Tier 1 COULD get two NAPTRS back 
>but might only get one. Even when two are returned, the calling party 
>could choose to follow just one path, i.e. to prefer the end user or 
>prefer the carrier path.

Well if the query is done by an edge IP PBX the assumption is that it 
cannot read the carrier path and only can use the end user 
path.  Presumably the carrier path eventually leads you to a terminal aka 
"u" NAPTR record for something like a LDAP that has AA associated with it?

>If carrier ENUM is in a separate tree then I have to do two queries to 
>determine that there is a record in neither versus one under my proposal.
>
>Finally, I don't think my proposal in any way implies that carriers have a 
>right to ENUM records absent a national opt-in decision.

Oh .. I dont believe that at all. If, for instance, German regulators opt 
out of e164.arpa because they still have this "thing" about .apra there is 
no reason a group of them could not agree to privately aggregate their 
endpoints in either a public or private tree in .DE order optimize their 
internal routing or promote the notion of SIP end to end  calling. People 
can and do anything they want to with the DNS and in fact that is what is 
happening now. In fact there are dozens of query response technologies that 
could work here 3761 only recommended one.

>  In fact, by proposing a common Tier 1 rooted in cc.e164.arpa I pretty 
> much make carrier ENUM depend on national opt-in to ENUM.

Again ..why do you want that kind of dependency?  Is is only because of the 
single query issue?

his is why it is so important now that we all attempt to understand what is 
the real underlying problem statement and what are the functional requirements.

>From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
>Stastny Richard
>Sent: Friday, July 23, 2004 2:06 PM
>To: Livingood, Jason; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn
>L, ALABS
>I think before we get into technical discussions, e.g. how this fits with 
>the DDDS algorithm and
>if it is wise to need always at least two ENUM queries to get an answer, 
>we should try to find
>out if this solution really is what is required, if this solution in 
>managable, etc.
>
>And last but not least, somebody needs to explain ITU-T and the national 
>regulators (NRAs)
>that c.c.e164.arpa is not longer a national opt-in decision, because I as 
>a carrier now have
>the RIGHT to have a delegation of my numbers in e164.arpa.
>
>
>nice try ;-)
>
>Richard
>
>         -----Ursprüngliche Nachricht-----
>         Von: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com]
>         Gesendet: Do 22.07.2004 17:28
>         An: enum at ietf.org; 'sdlind at att.com'; 'ppfautz at att.com'
>         Cc:
>         Betreff: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt"
>
>
>         Thanks to Penn and Steve for submitting this draft!  It appears 
> to present a workable technical solution to the discussions we've been 
> having on infrastructure vs. end user ENUM (putting privacy concerns 
> aside for a moment).
>
>         I have minor comments / suggestions that may make this draft more 
> usable in practice, and more acceptable to a wider audience.  This 
> involves a modification of the class of service acronyms.
>
>         The draft proposes two class of service acronyms:
>         1.  E2U - ENUM to URI, for End User records.
>         2.  E2C - ENUM to Carrier, for Carrier or Service Provider records
>
>         Which look like this, as cited in the draft:
> 9.0.3.5.7.6.8.7.9.4.1.joesenum.com
>                IN NAPTR 100 50 "" "E2C"   "" 9.0.3.5.7.6.8.7.9.4.1.telco.net
>
>         I submit that in the practice of manually provisioning records in 
> the DNS, in troubleshooting, or in general human use and reading of DNS 
> records or query results, that "E2U" and "E2C" are simply to similar to 
> one another visually.  I think that in practice this could cause 
> unnecessary difficulty and confusion.  I would recommend that a different 
> acronym be chosen for infrastructure uses that is unmistakably different 
> from "E2U."  This would pay heed to the human factors that will be 
> present when dealing with a large number of these records day in and day out.
>
>         The second concern is around the word "Carrier" and therefore the 
> "C" portion of the class of service acronym.  I believe that carrier is a 
> rather limited description of the entities which may have networks and 
> services associated with this class of service.  I would suggest instead 
> something focused on "service providers."
>
>         For these two reasons, I think that the draft should modify the 
> seconds acronym from "E2C" to something else, perhaps "SPR" (Service 
> Provider Record) or "SPU" (Service Provider URI).
>
>
>         Respectfully submitted,
>
>         Jason
>
>
>
>         Jason Livingood
>         Director - Forward Looking Communication Services
>         Communications Services Engineering
>         Comcast Cable Communications
>         215-981-7813
>         jason_livingood at cable.comcast.com
>

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<