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.
    ICANN Notice re: .ly | Log in/Create an Account | Top | 5 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.
    Examples of cases where publication is harmful
    by Anonymous on Wednesday April 14 2004, @07:43PM (#13392)
    http://www.ietf.org/internet-drafts/draft-iesg-rfc ed-documents-01.txt

    Examples of cases where publication is harmful

          This section gives a couple of examples where it might be appropriate
          to delay or prevent publishing of a document due to conflict with
          IETF work. It forms part of the background material, not a part of
          the procedure.

          Publish While Waiting: In 2003, the V6OPS WG was working on
          establishing evaluation criteria for the family of mechanisms known
          as "IPv6 transition mechanisms". The author of one of these
          mechanisms asked for publication as Experimental. The judgment of the
          WG chairs at the time was that publication of this document would
          remove sufficient energy from the group that the evaluation criteria
          work would not be finished, and the IETF would be unable to make a
          well thought out choice between mechanisms to pursue. Thus, the WG
          asked for this document not to be published at that time.

          Rejected Alternative Bypass: A WG is working on a solution to a
          problem, and a participant decides to ask for publication of a
          solution that the WG has rejected. Publication of the document will
          give the publishing party an RFC number to refer to before the WG is
          finished. It seems better to have the WG product published first, and
          have the non-adopted document published later, with a clear
          disclaimer note saying that "the IETF technology for this function is
          X". Example: Photuris (RFC 2522), which was published after IKE (RFC
          2409).

          Inappropriate Reuse of "free" Bits: In 2003, a proposal for an
          experimental RFC was published that wanted to reuse the high bits of
          the "fragment offset" part of the IP header for another purpose.
          There is no IANA consideration saying how these bits can be
          repurposed - but the standard defines a specific meaning for them.
          The IESG concluded that implementations of this experiment risked
          causing hard-to-debug interoperability problems, and recommended not
          publishing the document in the RFC series. The RFC Editor accepted
          the recommendation.

          Note: in general, the IESG has no problem with rejected alternatives
          being made available to the community; such publications can be a
          valuable contribution to the technical literature. However, it is
          necessary to avoid confusion with the alternatives the working group
          did adopt.

          The RFC series is one of many available publication channels; this
          document takes no position on the question of which documents the RFC
          series is appropriate for - this is a matter for discussion in the
          IETF community.
    [ Reply to This | Parent ]
    Starting Score:    0  points
    Moderation   -1  
    Extra 'Offtopic' Modifier   0  
    Total Score:   -1  


    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