Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda

From: "Stastny Richard" <[email-masked]>
Date: Sun, 20 Jun 2004 16:32:20 -0400

So given Steven questions, my "User ENUM" definitions
and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM",
 
I want to try to give an answer to question 1b first, before I address 1a
 
a: within User ENUM there exist privacy issues.
    set-up properly these issues do not exist in "Carrier ENUM",
    because either the information is not accessible or not usable
    by end-users.
    Note: all privacy issues with ENUM should thereore be discussed 
    in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"
 
b. "User ENUM" is end-to-end and therefore opt-in
 -  Service providers wanting to deploy a routing of calls
    between their networks avoiding the PSTN as interconnect
    need a tool on the Internet to achieve this goal. (This
    tool is also necessary if no PSTN exists anymore ;-)

  - They may choose to use the technology as defined
    in RFC3761 at al.

  - To achieve this they have to include ALL E.164 numbers assigend
     to them and they in turn assigned to the end-users they
     are providing service for (anybody an idea of a better wording?)
     so opt-in is not possible.

-   confederations of service providers may choose any domain in
    the DNS as root for their tree, they may even choose a "private DNS"
 
  - If a service provider  populates the tree only with E.164 numbers 
     assigned to him, a later merging of trees is trivial, because no overlaps
     exist.
  - currently also nor additional requirements on the ENUM protocol
    are known. If there are, please come forward now.
 
Warning: the above definition is only valid if "carrier ENUM" is
only used for routing to destination service providers hosting the
numbers they hold in the tree.
 
So
1a: What are the issues/problems that need to be addressed?

Recently some requirements have been discussed to use
ENUM and especially "carrier ENUM" for additional 
purposes,e.g. routing to transit providers if they also
provide gateways to the PSTN.
 
Although this is in principle possible with ENUM, this
is not recommended because it may cause conflicts in
domain ownerships and make it impossible to merge
trees later.
 
Since in most cases routing to the PSTN is involved,
this immediately raises the question of settlement and
alternative routes.

ENUM as it is now is not providing these functions, one
should use TRIP or OSP for this. 
 
The mini-BoF may discuss this issue and may come
to a conclusion. (reject the isuue or extend ENUM)

Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Richard Shockey [mailto:richard at shockey.us] 
	Gesendet: So 20.06.2004 20:35 
	An: Jeff Williams; Stastny Richard 
	Cc: enum at ietf.org 
	Betreff: Re: [Enum] Carrier ENUM mini-BoF Agenda

	>
	>
	> > >1a: What are the issues/problems that need to be addressed?
	> > >1b: What are the reasons that "Public" ENUM can't solve them?
	> >
	> > Regarding "Public" ENUM, I would like to ask that the list agrees
	> > on the following common understanding of "Public" ENUM:
	> >
	> > Based on the following already mentioned statement in RFC3761
	> >
	> > "Holders of E.164 numbers which want to be listed in DNS
	> > should contact the appropriate zone administrator according
	> > to the policy which is attached to the zone."
	>
	>   Yes and this indicates that the zone management will be making
	>this decision, with or without the consent of the users or any single
	>user.  Therefore this is insufficient, which I have been trying to
	>get across here... Oh, and BTW, a "Consensus" is also not
	>appropriate for which the zone management to declare without
	>being able to demonstrate that a "Consensus" is accompanied
	>by a vote of the participating zone users...

	Zone administration in the context of 3761 is the nation-state national
	regulatory authority period ..end of story.  That is the way it is in order
	to preserve and protect the integrity of the ITU E.164 numbering plan. It
	will not change, ergo further discussion of this matter is a waste of
	electrons.

	> > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and
	> > interpretable by anybody without restriction.
	>
	>   This needs to be changed for obvious privacy reasons.
	
	You are obviously not familiar with Internet 101. <sigh> the DNS is the
	DNS. All DNS data is available to all DNS users at all times regardless and
	without restriction. There are is NO AA in the DNS. Policy in the context
	SIP is controlled by the edge proxy's not the DNS.

	> >
	> > 2  currently most zone policies define the holder of the E.164
	> > number as the end-user,
	>
	>   Most, but not all.  And all is what is needed..

	again this is a nation-state issue in the context of 3761  you really need
	to read the documents

	
	> > 3. therefore it is the end-users decision to be listed in ENUM (opt-in);
	> > or at least his approval is required.
	>
	>   No that is not what is said or even inferred...
	
	certainly not in 3761 but if you would _read_ the various administration
	and policy documents coming out of various national ENUM Forums this would
	be self evident.

	I think Mr Stastny initial definition of Public ENUM is quite good and in
	the usual manner I'll probably steal most of it for various PPT slides. :-)
	
	As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I
	would prefer Carrier TN to URI translation mechanisms.
	
	One can begin by defining what we think Carrier "ENUM" is.
	
	Problem Statement: As the Internet becomes the predominant transport and
	routing mechanism for various forms of communications there needs to be a
	consistent, authoritative and reliable mechanism by which service providers
	can privately and reliably exchange Telephone Number to URI translations
	for all Telephone Numbers for which they have service control.
	
	Classic Telephone Number to PSTN routing mechanisms are well understood and
	the exchange of such inter-carrier data is well defined in the various SS7
	and Number Portability mechanisms.  Were service providers not able to
	exchange routing information no service would ever connect to another.
	
	The requirements of a Carrier TN to URI translation mechanism requires that
	the data be completely authenticated by the SP for ALL endpoints under its
	service control so that the aggregate inter-carrier database of all TN to
	URI translations is considered authoritative and reliable.
	
	Since the data is designed to permit optimized inter-carrier routing and
	nothing else, there is no requirement that the data be globally accessible
	or visible. In fact for security and privacy reasons reasons the exact
	opposite is true.
	
	What seems to be clear that in the absence of authoritative,
	authenticated  and reliable inter-carrier TN to URI database for voice
	communications services the default routing mechanism is the PSTN and for
	any number of reasons that is not a good idea in the long run.
	
	ENUM RFC 3761 defined one mechanism by which TN to URI translations could
	be accomplished for the General Case of Internet users using the DNS as the
	query-response mechanism. National Regulatory Authorities have generally
	defined the administrative policies and procedures surrounding 3761 as
	being OPT-IN for consumers, therefore the e164.arpa database may not be
	complete. And as a side bar, there are still significant problems in
	delegating various portions of the e164.arpa tree as of this date.
	
	The Carrier TN 2 URI service is clearly another case for a different set of
	users that has a different set of requirements which _may _require a
	different technical query-response solution.  This problem is much more
	roughly analogous to the problem of route announcements in BGP than the DNS
	(probably bad analogy) .

	Richard Shockey, Senior Manager, Strategic Technology Initiatives
	NeuStar Inc.
	46000 Center Oak Plaza  -   Sterling, VA  20166
	sip:rshockey(at)iptel.org   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: Jeff Williams <[email-masked]>
Date: Sun, 20 Jun 2004 20:56:27 -0400

Stastny and all,

>     in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"

  Good point.

>     tool is also necessary if no PSTN exists anymore ;-)

  I knew this was coming.  No tool is needed.  I suspect you
knew that before stating the above.  However a chance in the
standards track is needed, which I also suspect you know and
knew before stating the above is some standard or expected
level of good privacy protection is to be inclusive for User
ENUM.  I can however understand Carriers not liking
such privacy protections for User ENUM given potential
business plans or even existing business plans...

>   - They may choose to use the technology as defined

  I doubt that once that RFC3761 is understood by more and more
users they as users will...

>      so opt-in is not possible.

  Yes defined in this skewed way opt-in is not possible which is what
I have been saying all along for a couple of years now.  Yet opt-in
is being demanded and as such will need to be provided for.

>         -----Ursprüngliche Nachricht-----
>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: Plain Text (text/plain)
>               Encoding: 7bit

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