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

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Fri, 23 Jul 2004 16:59:21 -0400

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

Penn

-----Original Message-----
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
Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt"

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:
	    $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 
	 
	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

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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 25 Jul 2004 15:15:45 -0400

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.

Penn
-----Original Message-----
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
Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt"
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:
            $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

        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

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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum