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)


     
    This discussion has been archived. No new comments can be posted.
    Bring on the IANA Competitors | Log in/Create an Account | Top | 4 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.
    There are many parts of IANA
    by phoffman@proper.com on Monday February 03 2003, @03:54PM (#11082)
    User #2063 Info
    The discussion of the IETF maybe wanting a different IANA conflates IANA's control of the contents of the root zone with its other work for the IETF. With respect to the latter, see draft-iab-iana-00.txt [ietf.org], which is not an official statement of any kind but does show how the IETF might carve out what it needs from a future IANA.


    Someone has to be responsible for the content of the root zone. The decision of what goes into the root zone is clearly a mix of techincal, political, and policy items. The technical items include things like the NS records and glue records. The political items are the entire list of nameservers for any particular country. The most obvious policy item is the number of non-ccTLDs listed and who owns them.


    It is fine for IANA to be in charge of the technical items on its own. IANA should take explicit direction from ICANN on political and policy issues, and it should only do so only after publication of messages that anyone can read.


    Off-topic: IANA should get out of the IP address business. The RIRs are capable of ding this themselves.

    [ Reply to This | Parent ]
    Re:There are many parts of IANA
    by KarlAuerbach on Monday February 03 2003, @08:32PM (#11085)
    User #3243 Info | http://www.cavebear.com/
    I'm not sure I quite understand what you are saying.

    I absolutely agree that ICANN/IANA ought to be entirely out of the IP address allocation business.

    And I see no reason why ICANN ought to have any role in the job of handlng the "IANA Considerations" parts of RFCs.

    Nor do I see any reason why ICANN/IANA ought to have any role in the mechanical and clerical job of updating NS records for TLDs, all TLDs.

    Nor do I see any reason why IANA needs to validate TLD zone contents beyond that which is strictly and directly necessary to ensure that the delegation linkage from the root to each TLD is well formed. (This checking, by the way does not require a zone transfer - it can be done completely and with minimal intrusion using standard DNS queries.)

    ICANN's staff has said to me that it considers it appropriate for ICANN to induce a contract with ICANN as a precondition to the delivery of IANA services - such as the updating of ccTLD NS records - which is to my way of thinking a statement to the effect that ICANN is willing to sacrifice the actual operational stability of the Internet for no purpose other than to elevate ICANN.

    ICANN has transformed the ability to suggest to the US Dep't of Commerce's NTIA what TLDs ought to appear in the root into a power to dictate trademark policy on a worldwide basis. That is a role that has abolutely nothing with the technical job of IANA.

    IANA has been trusted. However, IANA will lose (if it has not already lost) that trust because it is being used as a hammer to shape ICANN's non-technical institutional and political agendas.

    The choice of who gets the nod to operate a ccTLD ought to be based on objective principles objectively applied. The choice ought not to be colored, cheapened, and discredited by bureaucrats who stand to benefit if they can use that IANA power to get one of the candidates to sign a contract with ICANN.

    The answer that is obvious to me, if not to the US Dept of Commerce, is that ICANN should not have any institutional linkage to the IANA mechanisms used to who gets to operate each ccTLD. In other words, the present practice of having commingled staff, comingled offices, comingled finances, and comaingled goals must be ended. With regard to ccTLD matters, ICANN and IANA should be divorced.

    ICANN and IANA have been so comingled that it is impossible to ascertain who of ICANN's staff makes what IANA decision, who of ICANN's staff has been involved in each IANA decision, or how much time or money ICANN's staff has spent wearing IANA hats. ICANN is making a gift to the US government by providing these services for no charge, that gift may or may not be appropriate, but no one can tell how much that gift costs.

    That leaves the issue of those TLDs that are not ccTLDs and not for administrative purposes (the latter including, for instance, in-addr.arpa).

    The answer to that question is the hardest, but the guideline we ought to follow is this: The IANA role should be insulated from politics and should be structured to deal only with those questions that a) directly concern the ability of the Internet to reliably, accurately, and swiftly deliver packets from a source IP address to a destination IP address and b) directly concern the ability of the DNS roots and TLDs to reliably, accurately, and swiftly process DNS transactions.

    Issues, such as the degree to which the domain name system is to be made the handmaiden of the trademark industry are not matters that ought to be allowed to intrude on the delivery of IANA services.
    [ 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