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 ENUM Outside .arpa
    posted by michael on Friday February 22 2002, @05:30AM

    There's so much going so fast with ENUM on the standards-making and political fronts that I just can't keep up (maybe some readers would like to help by submitting stories?). And some of the technical documents that get into the detail of call setup are very hard for me to follow. But one issue that I know matters is relationship of ENUM to the DNS. And one small but important part of that issue is the use of the anomolous .arpa domain in ENUM's DNS services. Comes now William Dutcher and Kevin McCandless with a draft informational RFC that proposes modifying RFC 2916 to remove references requiring that e164.arpa be used as the root domain for the DNS storage hierarchy for NAPTR records for ENUMs. Since .arpa is controlled by "IANA" (i.e. ICANN), and the proposal would open the door an alternate ENUM root outside ICANN's direct control, albiet not multiple ones, this is a significant proposal. Updated (twice)



    The .arpa domain has a special role in the internet, as it is used to support gateway location and Internet address to host mapping, making reverse domain lookups easy.

    Under RFC 2916, the domain e164.arpa was set aside for ENUM's use, forcing ENUM into a single hierarchical system not unlike the DNS. But, the funny thing is that the world's phone systems are in some ways less hierarchical than the DNS. Indeed, as Bob Shaw of the ITU put it Feb. 20, in an email to the IETF ENUM Working Group mailing list (ftp archive here), "A coordinated hierarchical symbol set (to use 2826 terminology) does not a priori require a single technical root." And this is the ITU, usually the paragon of centralization, talking. Shaw points out that instead "one can have a coordinated hierarchical addressing system that is not dependent upon a single technical root."

    But Dutcher and McCandless do not propose to go quite that far. Instead they say it should be open to pick some other single root outside .arpa. This change would,

    allow the developers of ENUM applications, as well as the providers of DNS infrastructures that support ENUM, a greater degree of flexibility in configuring DNS structures that will be used by ENUM. This change will also allow the RFC to guide the technical specifications of ENUM, rather than describe policy.

    It should be clear that this proposal is not suggesting that RFC 2916 be updated to allow for multiple values for that generic domain. In adherence to the goal of RFC 2916, there still should be one and only one domain at the root of the ENUM system. This document is simply suggesting that in any update to RFC 2916 that the value 'e164.arpa' be easily changeable to another value; especially in light of ongoing discussions between the IAB and the ITU. The relative merits of how that generic value is designated are discussed below.

    According to RFC 2916, the only DNS domain in which ENUM NAPTR records should be stored is the e164.arpa domain. The RFC is specific in this regard, as indicated in the Section 2 of the RFC:

    "2. E.164 Numbers and DNS

    The domain e164.arpa is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers, which want to be listed in DNS, should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with zone, just like in nor- mal DNS operations."

    In specifying the use of the e164.arpa domain for ENUM DNS records, the RFC may force designers of ENUM applications and systems into using a DNS root domain that does not meet the operational requirements of an ENUM application. For example, it may be more practical for an ENUM application to be in a different root-level domain. Several contributions to the ENUM Forum and to ITU-T Study Group 2 have suggested various tiered architectures, each of which may be more efficient and more practical if they are not tied by the RFC to the e164.arpa domain.

    Since RFC 2916 specifies .arpa as the TLD, it has created a policy decision rather than a technical decision. As a result, policy agencies are struggling with the .arpra issue instead of deciding whether or not global ENUM is an appro- priate approach. If this policy recommendation is removed from RFC 2916, these agencies will be able to address the TLD for ENUM without the burden of the TLD decision having been presupposed.

    Furthermore, the U.S. government supports a domain-neutral approach to ENUM implementation. Removing the reference to the e164.arpa domain for ENUM DNS systems will create a domain-neutral position in the RFC, and remove a mandate that may inhibit the flexibility of the design and develop- ment of ENUM systems.

    It's a first step. And there may be some reasons not to take the next one (haven't made up my mind on that one yet). As the ITU's Shaw himself noted in his email about the technical feasibility of multiple ENUM roots,

    A disadvantage of this model is that it requires a much more complex level of coordination among various systems; made more difficult with telecoms liberalization and the growth in facilities-based carriers.

    I know that it's a difficult transition for some but the issues are deeper and go beyond technical elegance of pulling a symbol set from one central computer or switch somewhere. There are other factors such as real world geopolitics, national sovereignty over critical infrastructure, CI security issues, intercept, etc

    Moral of the story? Lots of important stuff involving the DNS happens outside ICANN. This proposal does not address the many privacy and competition issues raised by ENUM. But it might get ICANN further out of ENUM, which can't be all bad.

    Update (1): The above was corrected by an ENUM expert who wrote, "Actually [.arpa is subect to] IAB control for specific and defined infrastructure purposes but the root is operated by IANA ..but the e164.arpa domain is operated by RIPE NCC."

    Update (2)And while that was going on, the ENUM mailing list carried reactions to the Dutcher and McCandless RFC that stop just short of a flamefest. While some were positive, the IAB old guard was scathing. The tone was set by Patrik Faltstrom, co-chair of the ENUM working group, who wrote,

    No. The domain name e164.arpa is decided by the IAB, and what is in use.
    ....
    If one is not using e164.arpa you are not following RFC 2916, and therefore you are not compliant to the ENUM standard.

    Not e164.arpa, not ENUM. Full stop.

    Have we been too hard on ICANN? Does IETF consensus formation rely on the occasional ipse dixit too? Or is it the corrosive effect of the DNS wars on everything it touches?

     
      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  
  • ICANNWatch.org
  • ENUM Working Group
  • here
  • submitting stories
  • draft informational RFC
  • RFC 2916
  •  
    This discussion has been archived. No new comments can be posted.
    ENUM Outside .arpa | Log in/Create an Account | Top | 6 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: ENUM Outside .arpa
    by dtobias (dan@tobias.name) on Friday February 22 2002, @06:42AM (#5012)
    User #2967 Info | http://domains.dan.info/
    I don't really understand the point of this... I'm not much of an expert in the ENUM system and how it's intended to interface with the DNS, but it seems to me that if you start with the principle that the entire ENUM-to-DNS mapping will be done in a hierarchy based on a single root (as both the old RFC and the new proposal do), it's fairly irrelevant exactly what the root is, whether it's e164.arpa or foo.bar.baz.example.org. The only essential thing is that everybody involved agree on which root to use; and replacing an existing RFC that specifies one in particular with one that leaves it up in the air seems to be a step backward in that regard.

    Of course, when you move from a technical to a policy level, there is a difference between different roots in terms of who controls them... if the new ENUM root were to be a subdomain of dantobias.com, for instance, it would give me an entirely unwarranted degree of control of that whole system including the ability to shut the whole thing down by cancelling the registration of my domain (after which it might resurface as a porn site...)

    However, I can't think of any place in the DNS structure that would actually take ICANN totally out of it, given that they (claim to) control the root servers. If the ENUM root were changed to a new TLD (.enum, for instance), it would have to be added to the root, which ICANN would at least attempt to have some say over (though I suppose the U.S. Department of Commerce could force it through against their objections). But the U.S. DOC might have equal ability to force through changes to .arpa against ICANN / IANA's wishes.

    On the other hand, if the ENUM root were to be within some existing TLD, such as subdomains of a second-level domain in .org or .gov or .int or a country code, then the root domain might belong to a particular entity which would give them some control over the process, but it wouldn't remove all ICANN control, as ICANN has taken unto itself the power to alter or revoke domain assignments (e.g., via UDRP decisions, and via redelegation of country code domains). Furthermore, embedding the ENUM root within a domain belonging to a specific organization seems like a bad idea for the long term, as that organization (whatever it is) might not forever be connected with the ENUM process, or might not even exist in the future -- if they let their domain lapse, would that shut down the whole ENUM service?
    [ Reply to This | Parent ]
    Re: ENUM Outside .arpa
    by joppenheimer on Friday February 22 2002, @07:22AM (#5013)
    User #5 Info | http://JudithOppenheimer.com
    "Lots of important stuff involving the DNS happens outside ICANN. This proposal does not address the many privacy and competition issues raised by ENUM. But it might get ICANN further out of ENUM, which can't be all bad."

    True that, for sure.

    But just as a heads-up, the ENUM Legal Experts Group of the (not IETF-related) ENUM Forum, chartered with developing ENUM implementation in the U.S., this week discussed using ICANN's formation as a model for "eliminating antitrust issues" so the Forum can discuss alt root-equivalent issues.

    Its the precedent of using ICANN as a policy model for anything, let alone doing an end-run around antitrust issues, that concerns me.

    (As a non-lawyer member of the ENUM Forum, I can attend Legal Experts Group meetings, but I'm not allowed to vote. ENUM Forum membership is free. And we could use some lawyers and other advocates, who represent the public and end-user interests.)

    [ Reply to This | Parent ]
    Re: ENUM Outside .arpa
    by dtobias (dan@tobias.name) on Friday February 22 2002, @04:07PM (#5020)
    User #2967 Info | http://domains.dan.info/
    Although .arpa has an anomolous historical origin as a reference to the now nonexistent ARPAnet, it has recently been redesignated as the Address and Routing Parameters Area, and hence is the logical place for "mapping" domain hierarchies (in other words, hierarchies used for reverse lookups or for resolving addresses of some other form to an Internet location, rather than creating addresses anybody is expected to type into a browser or other software by hand). That is why it was designated as the place for the ENUM lookup. If somebody has a good logical or technical reason why that address structure shouldn't be used, I'd like to hear it, but if it's just anti-ICANN politics, that's not a very good reason to change it. I dislike ICANN as much as anybody, but I'm not going to support reducing the logic of an addressing system just to score some political point against them.
    [ Reply to This | Parent ]


    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