ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    ENUM & VOIP 1.ENUM
    posted by michael on Tuesday April 30 2002, @07:09PM

    rfassett writes "The month of March 2002 provided reasonable clarification to the ENUM delegation process. Basically, an officially recognized government (of the U.N.) needs to provide the TSB with authorization to delegate within its country code. Then, only an entity approved by that government will find that its request to RIPE will be forwarded to the TSB without objection from Richard Hill, Counselor, SG2. Under these current interim delegation procedures (yet to be finalized in SG2), the chance exists that a government could communicate its desire for ENUM delegation to the TSB but, before the government's chosen entity gets its request in to RIPE, some other entity gets its request in first."



    Should no one be paying close enough attention, the 60 day period could come and go and, if no objections, the registry delegation be awarded by RIPE-NCC. So, there was a little hole that needed to be plugged here. Up to now, Richard Hill has been playing this watch dog role very well and objecting at the RIPE level when deemed necessary...but nobody can be perfect all of the time right?

    David Gross, of the U.S. Department of State, decided to take no chances with 1.arpa with this April correspondence to Mr. Houlin Zhao, director of the TSB. In part, it reads:
    "......we ask that the ITU Telecommunications Standardization Bureau (ITU/TSB) object to any request that it may receive from the RIPE NCC to any delegation of all or part of country code 1 within the domain e164.arpa (for example, 1.e164.arpa), to the extent that it would pertain to the United States, until and unless the United States Government has authorized the entity making the request. This would include both geographic and non-geographic area codes within country code 1, to the extent they apply to the U.S."

    "At the present time there are no ITU procedures in place to govern the process the ITU TSB will follow when it receives such a request from RIPE NCC. .....there is a possibility that RIPE NCC could receive a request for all or part of country code 1 within the domain e164.arpa that would in whole or in part pertain to the U.S. In the absence of an objection from the ITU TSB, RIPE NCC could delegate the code to the entity making the request, even though the U.S. had not authorized the entity making the request and would have objected had it known of the request."

    Consider the hole plugged, for North America anyway. The next question is: how does one get approval from the U.S. Department of State for the 1.arpa registry? Have not seen the defined criteria for this yet...but then again it is unlikely that it will take years of hamster racing and then a reform proposal to come up with either. By the way, how is it that all these new ENUM registries are being slated for admittance to the root server system? What happened to the controlled and limited process for reasons of stability. Seems this got routed around.

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • correspondence
  •  
    This discussion has been archived. No new comments can be posted.
    1.ENUM | Log in/Create an Account | Top | 15 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Re: 1.ENUM
    by fnord (groy2kNO@SPAMyahoo.com) on Wednesday May 01 2002, @06:34AM (#6104)
    User #2810 Info
    Ray, you state:
    By the way, how is it that all these new ENUM registries are being slated for admittance to the root server system?
    Am I not correct in understanding that the only part of eg: 1.e164.arpa that each registry would control would be the 1 (the regional code)? That is, there is and would be only a single registry for .arpa. -g
    [ Reply to This | Parent ]
    • Re: 1.ENUM by RFassett Wednesday May 01 2002, @06:47AM
      • Re: 1.ENUM by fnord Wednesday May 01 2002, @08:30AM
        • Re: 1.ENUM by RFassett Wednesday May 01 2002, @08:57AM
    Re: 1.ENUM
    by joppenheimer on Wednesday May 01 2002, @02:01PM (#6114)
    User #5 Info | http://JudithOppenheimer.com
    A few observations ...

    Internet companies see in ENUM an opportunity to shift the service, revenue and policy paradigms of the numbering space to the internet industry.

    Verizon on ENUM: "The integrity of a specific Global Service is determined by the way it is understood by the public in a specific context and implementation, as well as its particular numbering allocation, routing designation, and billing mechanisms as outlined in ITU Recommendations."

    VeriSign on ENUM: "E.164 ... pertains to regulated Public Telecom Services, not to Internet-based services provided to private users. Simply placing an E.164 number in an Internet based services directory shouldn't make that directory the subject of ITU jurisdiction and oversight. Indeed, it shouldn't make it the subject of any government regulatory schema." ... "Let providers and end users in the marketplace determine what applications are or are not associated with these numbers."

    (from an April 2001 ICB article):

    While not specifically written into any ICANN contracts, the ICANN FAQ covering the new VeriSign Agreement says, "Concerns have been voiced that the ENUM World initiative.... ICANN management believes that, when a registry operator seeks to provide services by leveraging the "DNS infrastructure" that it exclusively operates under its registry agreement with ICANN, those services should be subject to technical requirements and other policies developed through the ICANN process."

    Vint Cerf: "To the extent that enum relies on .arpa, that aspect surely falls under ICANN responsibility."

    (from an August 2001 ICB article):

    Worldcom: By agreeing at SG 2 that when E.164 numbers are entered into the Internet that PSTN service integrity is maintained, then foreign regulators could argue that you need to bring PSTN regulations into the Internet."

    My 2 cents:

    This last sentence could easily be rewritten to say, "... by agreeing at WIPO that when trademarks are entered into the Internet that WIPO policy integrity is maintained, then foreign legislators could argue that you need to bring WIPO regulations into the Internet."

    In fact WIPO trademark regulations have followed trademarks onto the internet. If WIPO regulation of its items - trademarks - followed trademark use onto the Internet, then it makes sense that ITU regulation of its items - E.164 numbers - should follow number use onto the Internet.

    Both are international organizations that regulate "items" - one words, the other, numbers. If WIPO regulation of words offline is applied to words online, then ITU regulation of numbers offline, should be applied to numbers online.



    [ Reply to This | Parent ]
    Re: 1.ENUM
    by jamielove (james.love at cptech.org) on Wednesday May 01 2002, @04:51AM (#6102)
    User #3323 Info | http://www.cptech.org/jamie
    Could someone explain to non-experts like me what ENUM is, why I should care about it, and what if anything it has to do with ICANN?

    Jamie
    [ Reply to This | Parent ]
    • Re: 1.ENUM by RFassett Wednesday May 01 2002, @05:50AM
      • Re: 1.ENUM by jamielove Wednesday May 01 2002, @06:52AM
        • Re: 1.ENUM by dtobias Wednesday May 01 2002, @07:58AM
          • Re: 1.ENUM by jamielove Wednesday May 01 2002, @01:16PM
            • Re: 1.ENUM by jamielove Thursday May 02 2002, @06:33AM
              • Re: 1.ENUM by dtobias Thursday May 02 2002, @06:57AM
              • Re: 1.ENUM by joppenheimer Thursday May 02 2002, @04:04PM
            • 1 reply beneath your current threshold.
  • 1 reply beneath your current threshold.

  • Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com