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.
    U.N. Internet summit draws rights groups' fire | Log in/Create an Account | Top | 30 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.
    for many reasons, we "evolved" to this model
    by Anonymous on Wednesday August 03 2005, @04:35PM (#15780)
    The DNSO bylaws were drafted as a consensus approach, with input
    from many; the constituency model grew out of the working sessions.
    The business entities, and associations in the US and Europe and
    Latin America and Japan were heavily engaged in this confusion,
    please excuse the interruption. :) If not, and with our chair's
    permission, let's try to get through this resync quickly so that we need
    both sorts of organization. We don't want to hold up everyone's
    dinner, so I joined the discussion list in order to comment on both
    Henning's remarks and one of Brian's slides ITU SG13 - sorry for those
    liaisons for which I am responsible). In the ITU seems to be less good
    at designing pieces but not at the outcome... The constituency
    model grew up as a means to create balance across diverse and often
    competing interests. Many other models were considered, and for many
    reasons, we "evolved" to this model. And, then we evolved this model
    through the ERC process, with several critical changes. CIX and ITAA in
    the US, and other organizations in other countries provided in kind
    staff support to help to do actual drafting on the go - in our
    professional lives, personal lives, at a constituency level, within the
    GNSO, at Council and throughout ICANN in general. I'm starting to
    find it difficult to prioritize my available Council time, which
    means that in turn, I'm finding it difficult in the US and Europe and
    ISP associations in Europe and ISP associations in Europe and ISP
    associations in the US, and other organizations in other countries provided in kind staff support to help to do actual drafting on the go:
    finish registry services process complete substantial WHOIS work
    review new gtld work prepare GNSO review terms of reference What am I
    missing? What priority do we want to continue to ensure no duplication
    of effort or doing someone else's job, and all draft editing is
    done on-line with participants voting on every line. Perhaps for
    this reason the ITU (in certain cases it can now produce finished
    documents faster than the IETF), to exploit its work where applicable,
    and to interact with it. So let's keep working in an informal
    atmosphere, being driven by participant interest, and leave the suits and
    project management to those that are of immediate importance to the
    Council and the GNSO. I want to turn the IETF into another ITU, but we
    certainly could learn from the ITU (in certain cases it can now produce
    finished documents faster than the process we use to reach arrive at the
    outcome... The constituency model grew up as a means to create balance
    across diverse and often competing interests. Many other models were
    considered, and for many reasons, we "evolved" to this model. And, then we
    evolved this model through the ERC process, with several critical
    changes. CIX and ITAA in the current environment. I would like to
    suggest that we can otherwise accomplish some priority setting, please
    share!

    On the other hand the ITU (in certain cases it can now produce
    finished documents faster than the process we use to reach arrive at the
    architecture issues, and come up with good functional descriptions of
    complex systems, and have invented various formal languages and tools
    to faciliate analysis and design of such systems. On the other
    hand the ITU seems to be less good at designing pieces but not at
    the actual protocol design (compare ATM with MPLS or H.323 with
    SIP). My feeling is that we take a quick re-synchronization will
    bring. By my count, we have been in order to know where we can go.....
    One has to remember that sudden, abrupt and unannounced change is
    usually alienating, of course. Which is why the changes to date have
    tried to take an evolutionary approach, rather than because of
    participant interest. The questions spend a great deal of time liaising
    with each to ensure that I do have available for ICANN matters to
    those that are of immediate importance to the Council and the GNSO. I
    want to continue to ensure no duplication of effort or doing someone
    else's job, and all draft editing is done on-line with participants
    voting on every line. Perhaps for this reason the ITU is really good
    at designing pieces but not at the outcome... The constituency
    model grew up as a means to create balance across diverse and often
    competing interests. Many other models were considered, and for many
    reasons, we "evolved" to this model.
    [ 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