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)


     
    The Big Picture An ICANN Reform Proposal
    posted by michael on Friday May 17 2002, @01:15PM

    Mikki writes "By its own admission, ICANN has become unwieldy, bankrupt and unworkable.

    This failure did not come as a surprise. ICANN has been the victim of an undefined mission under rules that continually change, creating a moving target that no corporation can hit. Unfortunately, ICANN's internal proposals for reform have not addressed these issues. The internal proposal does little for clarifying its mission, solidifying its rules, or even formulating a methodology for creating or changing these rules.

    In its current form, ICANN cannot fulfill the mandates of the White Paper and the consensus of the Internet community. The only course that will maintain the US Government's vision of privatization of the IANA functions will be a complete restructuring of the organization, beginning with its mission statement, and including every aspect of its operations, not limited to Board selection, supporting organizations, staff duties and responsibilities, public notice and comment, record keeping and access, and internal structure."



    Background
    The narrow technical mission of the White Paper achieved rough consensus in the Internet community. Such a mission would not need the overhead that is currently being consumed. To be specific, the narrow technical mission as envisioned in the White Paper would not necessitate nearly the structure of the current ICANN, and definitely would not necessitate the even larger structure that has been proposed by ICANN's president. The mission itself must be de-structured back to its original scope.

    Access to the Internet is quickly becoming the touchstone for success in the business world, the political world, and the world of individuals. In order to properly balance the public and the private interests in the Internet, the following changes and procedures are recommended:

    Mission
    The first and most important change in the structure of ICANN must come by carefully defining its mission. For this, we look back at the mandate of the White Paper, which achieved rough consensus from the Internet community. Four major points were enumerated as the mission for that "newco" would provide:

    1. set policy for and direct allocation of IP number blocks to regional Internet number registries;
    2. oversee operation of the authoritative Internet root server system;
    3. oversee policy for determining the circumstances under which new TLDs are added to the root system; and
    4. coordinate the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet.

    This mission can more clearly be defined into three specific duties:

    • Technical parameters
    • IP Address Space
    • Domain Name Matters

    These three duties can easily be performed by three separate entities, each responsible for a subset of the narrowly defined mission as prescribed by the White Paper. The advantage to separate entities is that "capture" becomes less of an issue. With the proper series of bylaws and procedures for each entity, inclusiveness, transparency, accountability, and bottom-up procedures can be ensured.

    IP Numbering Authority – IPNA
    The duties of the IPNA would include the following administrative and policy functions:

    • To act as the top level authority for delegation of IPv4 and IPv6 address blocks. These delegations will be made mainly to regional address registries (RIRs) such as today's APNIC, ARIN, and RIPE. As has historically occurred, it is expected that there will be occasional delegations outside of the RIR system.
    • To maintain the top level of the in-addr.arpa (and it's IPv6 equivalent) DNS hierarchy used for address-to-name mapping. (This task may be delegated to one of the RIRs if it is convenient to do so.)
    • To define overall policies for IP address allocations and apply those policies to guide the allocation of address blocks to RIRs and other entities.

    Technical Parameters Authority – TPA
    The duties of the TPA would include the following functions:

    • To record the assignment of protocol numbers and other such values as specified by IETF issued documents. This job will require coordination with the IETF to properly perform according to the "IANA Considerations" of those RFCs that contain them and to handle those situations in which RFC guidance is absent.
    Domain Naming Authority – DNA
    The duties of the DNA would include the following administrative and policy functions:
    • To maintain the zone file that defines the contents of the root. For the most part this involves maintenance of the NS records that indicate which DNS servers handle a particular top level domain (TLD) according to instructions from the entity or person who has the authority over that TLD.
    • To periodically publish that zone file to the operators of the actual root servers as well as to the public.
    • To ensure that the root servers are operated, either via the DNS Root Administrator itself or via an operations contract, so as to meet specified technical standards, perform according to specified service levels, and to meet certain obligations regarding security and physical infrastructure
    • To validate that the root server system is operating well.
    • To process requests to change the entity or person who has authority over a TLD according to procedures specified by the ccTLD Organization or the gTLD Organization, as appropriate.
    • To define what terms and conditions a ccTLD may be established or transferred to a new operator.
    • To define and apply the rules to establish or transfer gTLDs.
    • To define the rules to establish or transfer infrastructure TLDs (such as .arpa or .int.)
    • To define rules pertaining to the registration of domain names within gTLDs

    Implementation
    While the three entities charged with fulfilling the White Paper's mandates are to be legally separate and distinct, with no shared employees, trustees, directors, management or funds, each module must employ similar structures for ensuring bottom-up management, accountability and inclusive participation. Those structures must include:

    • Notice and comment periods. Notice of proposed actions will be announced and posted on the world wide web in sufficient detail and with sufficient time that interested parties may respond with comments. The administrator of the specific entity must evaluate the comments before making a final decision and must demonstrate that such comments have been reviewed and considered.
    • Public meetings. The public must be allowed access to the vast majority of meetings of the boards of any of these three entities. Minutes of meetings will be made available on the web in an expedited manner.
    • Members may vote to remove board members of any of the three entities.
    • Governments, as such, will not be permitted direct participation in any of the three entities.
    • Appeal process. An appeals process for interested parties should be created, for those cases where it is found that normal mechanisms are unsatisfactory, similar to the function of an Ombudsman, who has a free hand to act independently from any entity's board or staff.
    • Bylaws changes must require a supermajority of the board.
    • No current non-elected board members, officers, staff or trustees of the current ICANN will be allowed positions in any of the three entities for a period of five years.
    • Strict conflict of interest procedures must be implemented and adhered to.

    Specifics of the IP Numbering Authority
    The IP Address Policy Organization focuses on the needs and issues of concern to those who provide IP packet routing services and those who use IP addresses. This Policy Organization will be responsible for the creation of Policies to decide how and under what conditions address blocks of IP addresses should be assigned and sub-delegated. The output of this organization will be directives to an IP Address Administrator who will directly implement decided policies.

    It is expected that the staffing requirements will be minimal and essentially clerical. It is assumed that the job of maintaining the IP-to-name reverse lookup hierarchy will be delegated to the RIRs.

    Specifics of the Technical Parameters Authority
    This particular group would act as liaison to groups such as the IAB and IETF regarding technical implementation necessary to smooth operation of the Internet, simply administering the registries of parameter and protocol values according to the guidance given by those technical bodies.

    Specifics of the Domain Name Authority
    For better or worse, this will be the most complicated of the entities to structure, due to the inherent policy matters that are integral to decisions regarding top level domains, country code top level domains, intellectual property interests, etc. While the following structure may at first seem large, it is much less so than the current mechanisms within ICANN.

    Within the Domain Name Authority, there will be a more pronounced division between policy and implementation, with separate funding for each. We will look at policy and implementation modules separately.

    Domain Name Policy
    Within the domain naming policy module, it seems necessary to have separation between the gTLDs and the ccTLDs given history, differences in usage, difference in authorities, points of contention, etc.

    ccTLD Policy
    The ccTLD policy organization focuses on the needs and issues of concern to those who provide and use ccTLDs. The output of this organization are directives to an elected DNS Root Administrator regarding ccTLDs.. Such directives will generally be policy statements that instruct the DNS Root Administrator how to deal with requests for updates of ccTLD registration data - such as contact information and NS records.

    This policy organization will be responsible for the creation of policies to decide when new ccTLDs should be created, old ones removed, and how transfers of control of ccTLDs should be accomplished.

    gTLD Policy
    The gTLD policy organization focuses on the needs and issues of concern to those who provide and use gTLDs. The outputs of this organization are directives to an elected DNS Root Administrator regarding gTLDs.

    This policy organization will be responsible for the creation of policies to decide when and how new gTLDs should be created, how control is transferred, and the like.

    There will be great pressure for this policy to engage in policy making about things that go beyond how the ICANN DNS root and its contents should be managed: We are likely to see pressures to create trademark related policies and registry/registrar business operation policies.

    To avoid many of the pitfalls that spelled failure for the original ICANN, it is recommended here that the gTLD Policy Organization have explicit limitations in its organic documents to constrain the degree to which it may engage in what amounts to Internet lawmaking. And policies regarding business practices should be similarly constrained except for those needed to ensure that any failed DNS registrar or registry maintains enough recoverable assets and information so that a successor may pick up the pieces and resume services to the customers of the failed entity.

    Administration of DNS Policies
    The DNS Root Administrator oversees the operation of a DNS as previously listed. The DNS Root Administrator will be responsible for the establishment of operational policies regarding the operation of the root servers. These policies will be established through a notice and comment process

    The ccTLD policy organization will promulgate appropriate procedures. It is anticipated that the policies regarding the recognition of new ccTLDs and the re-delegation of existing ccTLDs will be the most complex and, at least initially, may require a close working relationship between the ccTLD policy organization and the DNS Root Administrator.

    The gTLD policy organization will promulgate procedures for the DNS Root Administrator with respect to gTLDs. The gTLD policy organization will issue directives to the Root Administrator to create or remove gTLDs.

    It is expected that the DNS Root Administrator will operate the DNS root servers initially via the loose federation of entities and individuals listed via http://root-servers.org. However, over time the DNS Root Administrator may chose to take a more direct role and operate some or all of its root servers itself.

    The DNS Root Administrator function will require staff and computing resources. Several of its jobs - such as monitoring the performance and availability of DNS root servers - may be contracted out. As with each module of each authority segment, technical requirements must be in balance with fiscal responsibility.

    Domain Name Rights Coalition
    www.domain-name.org
    Email: admin at netpolicy dot com.

     
      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  
  • http://root-servers.org
  • www.domain-name.org
  •  
    This discussion has been archived. No new comments can be posted.
    An ICANN Reform Proposal | Log in/Create an Account | Top | 3 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: An ICANN Reform Proposal
    by dtobias (dan@tobias.name) on Monday May 20 2002, @12:14PM (#6455)
    User #2967 Info | http://domains.dan.info/
    www.domain-name.org redirected me to www.domainnamerights.org, which in turn showed a completely blank page.
    [ Reply to This | Parent ]
  • 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