<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:87vblxvw58.fsf@mid.deneb.enyo.de" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="fw@deneb.enyo.de" photoname="Florian Weimer"
src="cid:part1.04090003.08070108@redbarn.org"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:fw@deneb.enyo.de"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Florian Weimer</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Sunday, November
30, 2014 2:08 AM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><div><!----><br>Wouldn't
be a first to step to cover root server *operators* (and root<br>DNS
server sites) to audits, lift them out of obscurity, and introduce<br>some
form of accountability?<br></div></div>
</blockquote>
<br>
accountability may be too strong a word for the art of the possible in
this case. a long time ago someone from icann (who is now long gone)
presented me (as isc president) with a proposed MoU that allowed either
party unilateral termination without cause, and specified that f-root's
address block (192.5.4.0/23) would become icann's property if the
agreement were ever terminated. after a few hours of "wtf?" from both
sides, i ended negotiations around the MoU and determined that no root
name server operator could ever be "accountable to" the icann
corrupt-o-thon, and that our accountability had to be much broader.<br>
<br>
years later, using a different negotiator on the icann side, an MoU was
negotiated between icann and isc. it's online, see reference #8 at
<a class="moz-txt-link-rfc2396E" href="http://icannwiki.com/ISC"><http://icannwiki.com/ISC></a>, noting that all of the "Key People"
listed on that page have moved on from ISC, but their current team is
excellent.<br>
<br>
additional anti-obscurity measures such as audits and additional MoU's
are worth discussing. the root server operators now have a very cordial
relationship to ICANN and they provide the core of the RSSAC. see
<a class="moz-txt-link-rfc2396E" href="https://www.icann.org/resources/pages/rssac-4c-2012-02-25-en"><https://www.icann.org/resources/pages/rssac-4c-2012-02-25-en></a> for
some contact info on getting started with that sort of initiative.<br>
<blockquote style="border: 0px none;"
cite="mid:87vblxvw58.fsf@mid.deneb.enyo.de" type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<div><br>It's not a bad idea to make sure that the data that goes
into the root<br>system isn't compromised, but right now, anyone can
already review<br>that, and there is even some public documentation for
the update<br>process. Contrast this with the situation on the operator
side, where<br>important information such as site selection criteria is
only<br>available under NDA (if at all).<br></div>
</div>
</blockquote>
<br>
each rootop has its own method of site selection. this is both an
anti-capture mechanism and a diversity-assurance mechanism. <span>i
believe that most rootops would be willing to speak on the record about
their site selection criteria if asked, and without an NDA. note that
i'm speaking of my beliefs, and not as a spokesman for any rootop other
than F (before) and C (now), because the rootops as an aggregate entity
have no spokesperson.<br>
<br>
</span>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>