[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] Carrier ENUM mini-BoF Agenda
Richard and all,
Richard: I have read all the relevant documents.
Richard Shockey wrote:
> >
> >
> > > >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>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--
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
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum