<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 12px;">Chuck,</div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 12px;"><br></div><div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px; border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;"><div>For Verisign, that accountability has led to an excellent operational record of 17 years of uninterrupted uptime for .COM.</div></blockquote><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">The effect does not appear to necessarily follow from the cause you claim. For example, I believe Verisign is on record as having concerns with the accountability of the root server system, yet the root has had significantly longer than 17 years of uninterrupted uptime. Similarly, .ARPA and its sub-zones, or even .INT which, as you are aware, are run by the body you claim to be unaccountable, all have uninterrupted uptimes I believe (but haven't verified) longer than 17 years.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">So perhaps the accountability associated with being a US-based for-profit corporation isn't necessarily the only factor in ensuring uptime of DNS zones (which, if you ask most DNS operations folk, given the design of the DNS and use of anycast, isn't all that hard assuming sufficient resources can be thrown at the problem).</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px; border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;">What stops an ICANN employee from going 'stark raving mad©ö</blockquote><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">Pretty much the same that would stop a Verisign employee from going stark raving mad: they'd (presumably) be fired. Or are you suggesting something about being a for-profit as opposed to a not-for-profit company disallows stark raving madness in its employees?</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">However, even if an ICANN employee did go stark raving mad and was able to bypass the numerous internal controls that would block inappropriate action (the "insider threat" scenario), the result of that madness would (in this context) be the submission of a request to the Root Zone Maintainer (currently in parallel to the Root Zone Administrator) to make a modification to the root zone. Since ICANN does not have access to the root zone that is published to the root servers, that would be the sum total of the result of the madness. The separation of functionality between the IANA Function Operator and the Root Zone Maintainer, similar to the two-key systems in US missile silos, reduces the likelihood that catastrophic events would occur.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">Well, it would, except the Root Zone Maintainer, if they went stark raving mad, can _unilaterally_ make any change they choose because they edit AND distribute the signed root zone to the Root Server Operators with no mechanism in place for a third party to verify that the change made by the Root Zone Maintainer matches the change that was requested by the IANA Function Operator before publication.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">And, in fact, if I recall correctly, such an event did occur back around 2004, albeit not as a result of stark raving madness, but rather when a bug in Verisign's root zone management software caused an unanticipated change in glue records for zones operated by AFNIC (detected by at least one ccTLD manager after the root zone had been published IIRC). Of course Verisign assures us the bug has been fixed (AFAIK, the code Verisign uses, as opposed to code ICANN uses, is not open source so it is difficult to independently verify, but given lack of reoccurrence in the intervening decade+, I think it safe to assume the bug has been eradicated) and has indicated that internal processes (AFAIK, undocumented but I'll admit not having looked for documentation on Verisign's Root Zone Maintainer processes — are those processes published anywhere?) are now in place to prevent a similar mistake from occurring, however that does not change the fundamental truth that the Root Zone Maintainer is the only entity that currently can unilaterally make a change to the root zone.</div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 12px;"><font face="Consolas"><br></font></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 12px;"><font face="Consolas">There is nothing in the architecture of the DNS or the root system that requires the process to be this way. As a straw man, one potential alternative model would be:</font></div><ol style="color: rgb(0, 0, 0); font-size: 12px;"><li style="font-family: Calibri, sans-serif; color: rgb(0, 0, 0); font-size: 12px;"><font face="Consolas">The proposed root zone changes submitted by TLD managers get publicly posted by the IANA Function Operator after validation.</font></li><li style="font-family: Calibri, sans-serif; color: rgb(0, 0, 0); font-size: 12px;"><font face="Consolas">The Root Zone Maintainer fetches the proposed change, applies the change to the root zone, signs the zone (thereby disallowing further change), and publicly posts the new zone.</font></li><li><font face="Consolas">The IANA Function Operator fetches the new zone, verifies the change implemented matches the change requested and distributes the zone to the Root Server Operator. If the change implemented doesn't match the change requested, you go back to step 1.</font></li></ol><div style="color: rgb(0, 0, 0); font-size: 12px;"><font face="Consolas"><br></font></div><div><font face="Consolas"><font>This model (one with myriad variations) provides true two-party controls, regardless of who the IANA Function Operator and Root Zone Maintainer are. If a model like this had been in place back in 2004, </font><span style="color: rgb(0, 0, 0); font-size: 12px;">there would have been a chance that </span>the AFNIC mistake would have been caught before the incorrect glue had be published to the global DNS by Verisign. This, of course, shouldn't be taken as criticism of Verisign — bugs, like stark raving madness, happen. This is merely an observation that the current multi-party root zone management process may not be providing the level of accountability people assume it does, regardless of the for-profit or not-for-profit status of the implementers.</font></div><div style="color: rgb(0, 0, 0); font-size: 12px;"><font face="Consolas"><br></font></div><div style="color: rgb(0, 0, 0); font-size: 12px;"><font face="Consolas">(I'll note in passing that if there a delay is inserted between steps 1 and 2 or between step 2 and 3, an appeal/injunction mechanism could (potentially) be applied. I have no opinion on whether this would be a good idea or not.)</font></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">In all the discussions I've seen on the transition of the stewardship of the IANA Functions contract related to the Root Zone Management function, there has been precious little discussion of the actual root zone management processes despite the fact that, given NTIA will no longer be involved, those processes MUST change and those changes will have DIRECT operational impact on the Internet. I'll admit to a bit of surprise about this.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px; border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;">or a post-transition ICANN from going Œstark-raving-greedy©ö?</blockquote><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">I'll admit to not following the ICANN Accountability stuff all that closely — I'm just a technical person (or try to be) so much of that discussion is beyond me. However, my understanding (which is probably wrong) is that ultimately, Verisign, being a for-profit company incorporated in a state that is (perhaps unfairly) known to have the least stringent corporate responsibility requirements, has a fiduciary responsibility to its shareholders to make a profit. ICANN, being a California public benefit not-for-profit, has a fiduciary responsibility to serve the public interest as interpreted by the State of California. While a for-profit like Verisign being "stark-raving-greedy" is arguably appropriate (at least according to the laws of the state of Delaware), I have some skepticism that State of California would see an ICANN that was "stark-raving-greedy" as being in the public interest.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">And, of course, that is ignoring other accountability mechanisms already in place at ICANN and whatever additional accountability mechanisms are put in place as a result of the transition.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">But I'm confused: my understanding, which is apparently flawed, was that the CCWG (not the CWG) is focused on improving the accountability of ICANN to the communities it serves and I wasn't actually asking about corporate accountability, I was asking about the accountability of the root zone process.</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">Regards,</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">-drc</div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;">(ICANN CTO, but speaking only for myself)</div></div><div style="color: rgb(0, 0, 0); font-family: Consolas; font-size: 12px;"><br></div><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1553148731;
mso-list-template-ids:-2115107330;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></body></html>