[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enum] Carrier ENUM mini-BoF Agenda

To: Peter Williams <home_pw at msn.com>
Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda
From: Jeff Williams <jwkckid1 at ix.netcom.com>
Date: Mon, 21 Jun 2004 00:07:27 -0700
Cc: enum at ietf.org, richard at shockey.us
List-help: <mailto:enum-request@ietf.org?subject=help>
List-id: Enum Discussion List <enum.ietf.org>
List-post: <mailto:enum@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
Organization: INEGroup Spokesman
References: <BAY3-F24TEewKlrIcKh000110a7@hotmail.com>
Sender: enum-bounces at ietf.org

Peter, and all,

Peter Williams wrote:

> >
> >
> >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.
>
> Lets be more careful, and perhaps more informative and precise.
>
> Can you cite the IS<->ITU-T agreement pertaining to this specific issue,
> please. For example, are you saying that all carrier ENUM
> registrations/listings performed out for all US telco carriers (PSTSN and
> regulated VoIP) must be handled by ***** company? Becuase they happen to
> have won an ICANN bid for registering _host_ domain names, beneath .us?

  I think Richard was trying to say this in his own terms/words.  Of course
the US does not always and recently rarely adheres to ITU agreements
or proposals as many were not made in cooperation with DOC/NTIA
or NIST for a couple of examples.

>
>
> Is ICANN secretly regulating infrastructure ENUM now?

  ICANN is certainly attempting to have some influence.  To the extent
that industry or commercial and non-commercial entities will be accepting
remains inconclusive.  Some will and some won't but the IP GNSO constituency
is attempting to garner more and more Commercial organizations in becoming
more accepting...

>
>
> There are various formal arrangements between IETF/IS and ITU, most of them
> being informal arrangements concerning shared committee work, overlap, and
> enabling ITU to reference certain grades of IETF documents when issuing
> international standards under the authority of the UN. If the ENUM WG's
> engineering deliberations are subject to specific rules both for standards
> making, and for any and all operations, and it is not mentioned or
> referenced in the RFC being cited and sicussed as the source of the
> undersatnding about public ENUM, we HAVE to fix this. This is VERY serious
> omission. BIG RED FLAG.

  I agree, a very big red flag...

>
>
> On the issue itself, versus WG procedure and quality of standards:
>
> we must remember that DNS is but one place where users/carriers may list the
> already registered E.164 numeric descriptor name form, as a new name - one
> formulated using the IETF standardized name form for domain names. Integrity
> and listing rules for this name form pertain to DNS adminsitration, not
> ITU-T: period. Who issues E.164 names per se is not relevant to IETF,
> particularly.
>
> In certain special zones, e.g. .arpa, DARPA program managers in IETF WGs
> have the authority to use US government authority for research purposes, and
> possibly purposes advancing matters handled normally by the US State Dept -
> e.g. interaction with an international organization such as ITU, under
> international (not US) law. I suspect most of us would be happy that we get
> a government agency used to negotiating engineering issues in ISO/ITU on our
> side, once such issues start to impact or constrain the engineering
> activities.
>
> >
> >
> >
> >> > 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
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

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

References:
- Re: [Enum] Carrier ENUM mini-BoF Agenda
  - From: Peter Williams

Prev by Date: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda
Next by Date: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda
Previous by thread: Re: [Enum] Carrier ENUM mini-BoF Agenda
Next by thread: Re: [Enum] Carrier ENUM mini-BoF Agenda
Index(es):
- Date
- Thread