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)


     
    ICANN Meetings Planning Ahead for the Next ICANN Meeting
    posted by michael on Wednesday April 18 2001, @03:37AM

    ICANN has opened pre-registration for its next meeting in Stockholm, Sweden. So now is a good time to make some simple suggestions that would improve the openness and transparency, not to mention basic fairness and efficiency, of the meetings. As a starting point for discussion, I offer my really very modest list (honest) of five things ICANN could and should do. What's yours?



    The number one thing that ICANN should do, is vow to publish its agenda for Board meetings, and especially the text of all proposed Board resolutions, 21 days in advance for all matters other than dire emergencies. This is a long lead time, but it is essential for at least three reasons.
    1. Some constituencies - especially the non-commercial constituency - are not nimble and have rules designed to ensure full discussion and broad representation. The result is that they are disenfranchised when anything comes up at the last minute. Indeed, the more multi-national and heterogenous a constituency, the more it is democratic and representative (especially of those with no travel money and limited time) in its internal workings, the less able it is to respond quickly to last minute surprises from the ICANN staff. The result is that the field is limited to less international, less broad-based, and often less democratic constituencies that often have few (usually wealthy) active participants.
    2. A long lead time is also important to meaningfully enfranchise non-English speakers and those who don't have the good fortune to be US-trained lawyers. So long as key documents are written in that subspecies of US English called "lawyerese," even native English speakers are going to need translation assistance. And that requires time.
    3. If democracy is to be meaningful at ICANN (still a very open question) then elected Board members should have time to consult, if they wish, with their constituents. In order for this consultation to be meaningful, both the Board members and the constituents need access to the resolutions that the members will be asked to vote on. This applies just as much for the corporatist (PSO, ASO, DNSO) members as for the at-large.

    The number two thing ICANN should do is provide translations of Board resolutions into as many of the major UN working languages as practicable at least 14 days before the meetings. I don't personally think that it is always critical for ICANN to translate into the host language if it cannot find a local sponsor to underwrite the costs; that depends on the circumstances. Take, for example, Swedish. It's not a language spoken around the world, and I'd guess that over 90% of the local participants will speak good English.

    The number three thing ICANN should do is replace the real-time scribe with some sort of professional transcription. They're nice folks, and for amateurs, they are doing a pretty good job (although I wish for e-mailed questions they could figure out a way of just cutting and pasting the email rather than mis-paraphrasing it). But it's significantly below professional quality scribing, and this creates real problems. Non-native speakers depend on the scribing when they cannot follow the dialog. Everyone will depend on it the day the real-time connection dies. And it provides the most accessible record of meetings for people in the wrong time zones, or looking things up after the fact. Yet, a comparison of the scribing to the event show that the scribes leave a lot out - and occasionally editorialize (indeed, sometimes they drop in an editorial comment, then delete it from the final record). Non-native speakers with thick accents find their remarks mangled sometimes, but this happens to native speakers too. Almost every time I've commented with more than one point I've found the scribing limited to one point chosen seemingly at random.

    These first three things are essential, should be non-controversial, and all could be implemented by the next meeting. The next item on my wish list is more controversial, and I don't have much hope of ICANN actually doing it. But it needs to be said anyway. ICANN claims to be open and transparent. It promised the US Congress that it would hold open Board meetings. Yet, increasingly, the real work and the real decisions are made at the secret telephone meetings, and at secret pre-meeting meetings. Take, for example, the Melbourne meeting. We have an authoritative account from Karl Auerbach of a Board meeting in all but name the night before the public meeting. Either secret meetings should stop, or ICANN should stop the charade of ‘open' meetings. Don't hold your breath.

    My fifth and last suggestion is that ICANN either work to enable satellite meetings or vastly upgrade support for e-access to constituency meetings and other events besides the main events. It's not reasonable to expect people from all over the world to attend meetings in person. Internet access would be the best way to go, but in the interim it might be helpful to organize parallel meetings at geographically diverse places. 0It may be that ICANN cannot, at least in the short run, pay to rent a room for the meeting, but it could at least set up some criteria for recognizing a satellite meeting as official, explain how 2-way videoconferencing might be set up, and discuss the extent to which participants in those meetings would be able to participate in the main meeting. This is a job for the meetings committee.

    OK, that's my list. What's yours?

    [To respond, or start a new comment thread, click the "Send Your Comment" button in the yellow box to the right.]

     
      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  
  • authoritative account
  • next meeting in Stockholm, Sweden
  •  
    This discussion has been archived. No new comments can be posted.
    Planning Ahead for the Next ICANN Meeting | Log in/Create an Account | Top | 2 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: Planning Ahead for the Next ICANN Meeting
    by tbyfield (reversethis-{moc.xinap} {ta} {dleifybt}) on Wednesday April 18 2001, @03:32PM (#542)
    User #44 Info
    here are a few more:
    - the board should review,formalize, and enforce its policy with regard to the presence, protocol, and participation of staff (e.g., mclaughlin and touton) and outside counsel (sims) in board meetings. as things stand, the tail (staff) wags the dog (board) far too often; that needs to stop.

    - in its contracts with berkman, ICANN should stipulate that berkman webcasts proceedings in a format that's as interoperable and open as possible -- that means quicktime, not realmedia.

    - no meeting should take place that isn't fully documented, including a webcast. in the last two meetings (marina del rey and melbourne), the IANA/ICANN-ccTLD meetings weren't webcast; at the melbourne meeting, the membership at large meeting wasn't webcast either. in light of what transpired in the MDR ccTLD meeting (links to a third-party audio recording i tracked down are here), it's pretty obvious why that happened.

    - the board should announce at the outset of any given procedure which particular rule of order will govern a quantitative canvassing of board sentiment. in the new gTLD session at marina del rey, the Afilias proposal was passed in contravention of ICANN's bylaws by a vote declared in midstream (by staff) to be a "straw poll" not consensus. these kinds of rhetorical hijinks are completely unacceptable (see my account here).

    there are many more reforms that need to happen, but these -- in addition to the excellent proposals michael has made -- would be a good start.

    [ 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