Inside ICANNWatch  
Submit Story
Lost Password
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
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.
    VeriSign Announces Faster Updates for .com and .net | Log in/Create an Account | Top | 11 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    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.
    Verisign Now Needs to Move Forward
    by Anonymous on Friday July 09 2004, @11:10PM (#13905)
    Now that ICANN has filed their reply to the
    Verisign lawsuit, Verisign needs to move forward
    with New Services that people want. ICANN has
    no say, and Joe Sims makes it clear that ICANN
    does not stand in Verisign's way.

    Verisign can increase shareholder value by putting
    the ICANN era behind them. The market place will
    rally around the Verisign run .COM and .NET TLDs.

    People do not want to see .COM or .NET go down
    the path that .ORG took, with an out-sourcing
    arrangement to a closed circle of religious
    zealots, who can not keep their servers running
    and who openly admit they are working on such
    high-tech experimental systems, they do not even
    understand them.

    .COM and .NET owners do not want to be part of
    some academic/government/geek experiment. It is
    time for Verisign to move to serve the marketplace
    of people and companies who understand what
    reliable, stable and secure telecommunication
    systems can deliver. The .COM and .NET owners
    expect the best, not the lowest bidder.

    The rapid TLD server update is just one of
    many upgrades to the .COM and .NET services
    that Verisign can do, without requiring any
    approval from ICANN. There are a large number
    of other services which can now be delivered.
    It is time for Verisign to move forward and
    ignore ICANN. The .COM and .NET owners need
    to focus on next generation Internet services
    and customers, not religious zealots from the
    last century, parading around the world acting
    like fools.

    [ Reply to This | Parent ]
    While .COM and .NET Progress - .ORG Fails
    by Anonymous on Saturday July 10 2004, @09:34AM (#13910)
    On Thursday night, 1 July, approximately between 9PM to 11PM EST, we started observing reports regarding time outs reaching UltraDNS .ORG Name Servers. We understand the problem was a result of systems upgrades by UltraDNS and has been corrected.

    As we continue to investigate the issue, we will be able to better inform you of the outcome of our findings. We are taking steps to insure that this situation will not recur.

    Please let me know if I can provide any further information.

    Bruce W. Beckwith
    VP, Operations
    Public Interest Registry
    [ Reply to This | Parent ]
    This is Compatible with IPv9 and IPv8
    by Anonymous on Saturday July 10 2004, @11:27AM (#13912)
    Verisign has to make these changes to be
    compatible with IPv9 and IPv8.

    Note: It is interesting to see that the
    ICANNwatch web-server is using IPv8. There
    are 49 bits in the IPv9 and IPv8 header.
    IPv4 has 48 bits. High-tech equipment shows
    that ICANNwatch now is sending 49 bits
    and the 49th bit is set to 0. Good job!!!

    By the way, the Chinese read left-to-right
    so the 49th bit is the first bit for them.
    High-performance packet switching equipment
    sends the first 49 bits in Reverse Order
    down the wire. IPv8 packets can be sorted
    out from IPv9 packets after receiving the
    first bit. That is very fast and required
    for Terra-Bit speeds.
    [ Reply to This | Parent ]
    TTL value to set the Extended Address Bits
    by Anonymous on Sunday July 11 2004, @04:46AM (#13915)
    Verisign plans to keep the default TTL Value set
    to 48 Hours (2 Days), to trigger IPv4-mode.

    IPv9 and IPv8 use the right-most 12 bits of the
    TTL value to set the Extended Address Bits.
    TTL values are shortened by shifting the other
    bits, 12 bits to the right. Large TTL values
    result in much shorter cache times, which is
    fully-compliant with the IEEE and ITU standards.

    In those 12 bits, the right-most bit is 0 or 1
    to allow DNS Resource Records to be sent as pairs.
    Two 32-bit A Records, for example, can be combined
    to create 64-bit addressing.

    The other 11 bits are divided into a 4 bit field
    and a 7 bit field. That is 2,048 unique prefixes
    or suffixes, depending on the other addressing.
    A prefix is like an area code, a suffix is like
    an extension number for a phone on a PBX. Most
    humans are familiar with both forms of extended
    [ 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