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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 19 Jun 2004 18:03:39 -0400

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

1. NAPTRs in "Public" DNS shall be accessible, retrievable and
interpretable by anybody without restriction.
2  currently most zone policies define the holder of the E.164
number as the end-user, 
3. therefore it is the end-users decision to be listed in ENUM (opt-in);
or at least his approval is required.
4. the end-user has either direct or indirect influence on
the content of  the NAPTRs

If there is a requirement to implement ENUM in a different way
by any entity or confederation of entities, especially with a
different policy incompatible with the policy of the appropriate
zone administrator (in e164.arpa in most cases the ITU-T and the 
NRAs), this may be done in any kind of different tree and is
called operator, carrier or infrastructure ENUM (it would
also be nice to agree on one name)

I could offer to present the current European (ETSI) position
if  I am given a 10 min slot.

>2. Requirements for a solution without a specific recommendation on what
>that technology may or may not be appropriate.

I cannot completely parse this sentence, could anybody
elaborate please:

Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Richard Shockey [mailto:richard at shockey.us] 
	Gesendet: Sa 19.06.2004 22:15 
	An: enum at ietf.org 
	Cc: James Seng; Stastny Richard; paf at cisco.com 
	Betreff: Re: [Enum] A note from your chairs on the Agenda for IETF 60 including this discussion on Carrier ENUM - Addendum

	At
	
	>The second hour will then shift to a discussion of Carrier -
	>Infrastructure ENUM ( what ever you want to call it ) That discussion will
	>be led by James Seng and Richard Stastny with myself providing continuity
	>and context to the existing work.
	>
	>Individuals wishing to make formal ID contributions and or requesting time
	>to speak on Carrier ENUM discussions are requested to get your ID
	>documentation in a soon a possible and request time from the mini-BOF chairs.
	>

	I should have added to this note that the Carrier ENUM mini-BOF should be
	limited to a discussion of :
	
	1. The problem statement. To this end I'm reminded of Steve Lind's succinct
	proposal
	
	1a: What are the issues/problems that need to be addressed?
	1b: What are the reasons that "Public" ENUM can't solve them?
	
	2. Requirements for a solution without a specific recommendation on what
	that technology may or may not be appropriate.

	
	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: Sat, 19 Jun 2004 23:42:29 -0400

Stastny and all,

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

> interpretable by anybody without restriction.

  This needs to be changed for obvious privacy reasons.

> 2  currently most zone policies define the holder of the E.164

  Most, but not all.  And all is what is needed..

> or at least his approval is required.

  No that is not what is said or even inferred...

> the content of  the NAPTRs

  Direct is necessary.

> I cannot completely parse this sentence, could anybody

 I really couldn't either...

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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 20 Jun 2004 14:39:26 -0400

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.

  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.

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

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

---

From: Jeff Williams <[email-masked]>
Date: Sun, 20 Jun 2004 21:02:18 -0400

Richard and all,

  Richard:  I have read all the relevant documents.