[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: [Enum] Carrier ENUM mini-BoF Agenda
Stastny and all,
Stastny Richard wrote:
> 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"
Good point.
>
>
> 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 ;-)
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
> in RFC3761 at al.
I doubt that once that RFC3761 is understood by more and more
users they as users will...
>
>
> - 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.
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.
>
>
> - 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>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>
>
> ------------------------------------------------------------------------
>
> 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
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum