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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 23 Jul 2004 14:08:20 -0400

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: Fri, 23 Jul 2004 14:38:08 -0400

At 02:06 PM 7/23/2004, Stastny Richard wrote:
Content-Class: urn:content-classes:message
Content-Type: text/plain;
        charset="utf-8"
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.arp
Given that the administrative policies and procedures regarding the various 
trees of e164.arpa are by IAB/ITU definition nation state matters I 
continue to find it baffling that service providers would want to put the 
administrative, policies and procedures surrounding their internal routing 
data within the grasp of their (NRA's) regulators.

What are you all thinking?
nice try ;-)
Richard

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

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Jul 2004 15:12:12 -0400

>>>>> "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: Jeff Williams <[email-masked]>
Date: Sat, 24 Jul 2004 02:17:09 -0400

Richard and all,

> What are you all thinking?

 It is baffling to me that you could pose such a question.  The answer
is simple, that the technical IT community obviously does not wish
to listen to the stakeholders/users they directly or indirectly serve, especially
with respect to security and privacy laws. The IAB/ITU seems to not
be represented adequately by the stakeholders/users or consumers of
use of technology's of all types.  Hence nations and regions, such as the
EU, have seen fit naturally that NRA regulators with the respective
national government oversight, are necessary in order the adequately
protect their stakeholders/users/citizens.

> <http://www.neustar.biz> ; <http://www.enum.org>

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827