[kc@localhost: requesting hard data sources on ramifications ofverisign wildcard] (fwd)

["Henk Uijterwaal (RIPE-NCC)" <]

FYI and apologies for duplicate mails.


----- Forwarded message from k claffy kc@localhost -----

  Date: Thu, 16 Oct 2003 12:26:15 -0700
  From: k claffy kc@localhost
  Subject: requesting hard data sources on ramifications of verisign wildcard
  To: nanog@localhost


  as already mentioned, fascinating public policy theatre
  is going on in DC on the verisign wildcard issue, see
  	http://secsac.icann.org/
  [all video and even transcripts of both meetings online. go icann.]
  you are encouraged to read through all of it before making public comments
  on this issue at nanog. (or, hope springs eternal, to this list.)

  caida has the following request on behalf of icann's secsac committee
  [an exceptionally competent group who is approaching this issue
  with impressive speed, equaniminity, and integrity.
  	http://www.icann.org/committees/security/
  i believe we're in good hands here. let's give the process a chance
  and constructively contribute where we can.]

  a common theme over the last week is an admitted lack of hard data
  [rather than lists of theoretical breakages, and anecdotal evidence,
  and predictions] from the operational community on actual loss of
  stability in Internet performance or functionality.
  david from XO gave an outstanding talk on 7 oct,
  	http://www.icann.org/presentations/shairer-secsac-dc-07oct03.ppt
  but, as with many other providers, he deployed the bind patch
  within 24 hours so he didn't really have useful hard data
  to put on the table.  i get similar comments from others.
  ben from harvard also gave some hard alexa data, fwiw
  	http://www.icann.org/presentations/edelman-secsac-dc-15oct03.ppt
  but from a specific vantage point.  we need more of these.

  icann's secsac committee is in a much stronger position to
  provide technically sound and equitable guidance if we can
  provide them with as specific, concrete examples (*hard data*)
  that indicate extent of various types of breakage.

  please save the arguments regarding the legitimacy and short notice
  of this request until you've read the hours of discussion about
  it that has already occurred among many qualified folks in DC
  (and in any case the meta-issue still stretches AUP of nanog list).

  the inconvenient reality is that the secsac committee needs concrete
  data (imagine), in addition to bulleted lists of things that break,
  for the policy process to work most effectively here.  and nanog is
  in a position to make a difference.  you are hereby encouraged to do so.

  please send any hard data reflecting observed ramifications on
  security and stability of Internet infrastructure to

  	secsac-comment@localhost

  no hard data will be refused service
  k

----- End forwarded message -----