<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{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:1924416676;
mso-list-template-ids:-62382820;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Steve<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Based on what you write below, I still see a clear distinction between the policy decisions, and their later implementation by the IANA. Of course the policy
and the implementation are interdependent. But none of your examples undercut the argument for structural separation.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">IPv6 addresses: RSSAC and SSAC are obviously on the ICANN, policy side of the equation. If they recommend adding v6 addresses to the glue records, IANA implements.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">IDNs: Obviously, like any new TLD addition whether to authorize them or not was a policy decision, albeit dependent on prior standardization work by the IETF
and tests.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">DNSSEC: You ask “Should the root be signed? If so, how? What should the rules be
for assuring trust in the process? How often should the root key be changed?” - These all seem to be policy decisions to me.
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I would note that separating IANA implementation from policy seems a lot less intricate and complicated to me than the separation of registry and registrar
functions, which was done 15 years ago with huge economic and technical consequences.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">When you talk about “complete separation of policy and administration” I wonder whether you have an unrealistic notion of separation in mind, which is not what
anyone advocates. It doesn’t mean a lack of communication, for example. It is more like a clear division of labor or function. Sure, there are bound to be some grey areas, but that shouldn’t be used to rationalize complete integration of the two.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also, you ask for example of where the current configuration has failed to operate properly. But this misses the point: under the current configuration, you
are _<i>contractually obligated</i>_ to run the IANA functions in a way that meets standards. Once that USG contract goes away, what is the guarantee that this will continue to happen?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> discuss-bounces@1net.org [mailto:discuss-bounces@1net.org]
<b>On Behalf Of </b>Steve Crocker<br>
<b>Sent:</b> Sunday, March 16, 2014 4:29 PM<br>
<b>To:</b> Avri Doria<br>
<b>Cc:</b> discuss@1net.org List<br>
<b>Subject:</b> Re: [discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Avri,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mar 16, 2014, at 2:53 PM, Avri Doria <<a href="mailto:avri@acm.org">avri@acm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi,<br>
<br>
One of those principles for me would be:<br>
<br>
- Strict functional separation of the policy making and administration<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is not as simple as it might seem. It depends on exactly what you mean by “policy.” I expect your focus, along with many others, is the decisions related to delegation and re-delegation, i.e. which names are added to the root zone
who is allowed to operate them. Perhaps “policy” also includes various issues related to public interest, compliance, etc. For all of these, I would agree strongly that we do not want to burden the IANA group or the operation of the IANA function with those
sorts of issues.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the other hand, here are some other things that have been treated as policy issues in the past that are intimately related to the operation of the IANA function.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
DNSSEC. Should the root be signed? If so, how? What should the rules be for assuring trust in the process? How often should the root key be changed? Etc.<br>
<br>
Quite obviously we’ve gotten past the first few questions, but there was a lengthy period several years ago where the answers to these questions were stuck in limbo. Even now, there are important questions about the frequency of key rollover, etc. that are
not yet reduced to standard practice.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
IPv6 addresses for root servers. Should IPv6 addresses be included as glue records for the root servers?<br>
<br>
Again, we are now well past this question, but there was a surprisingly long period where several of the root servers were accessible via IPv6 addresses but those addresses were not in the root zone. Worse yet, there was no process in place for figuring out
whether it was ok to add them and what the issues might be. (Eventually RSSAC and SSAC did an ad hoc study to provide advice to IANA to get it done. (See SSAC reports SAC 018 and supporting reports SAC 016 and SAC 017.)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
IDN TLDs. Are IDNs ok as top level domains?<br>
<br>
It took a long time to work through these issues. Along the way, eleven names in various scripts were added to the root zone for testing and evaluation.<o:p></o:p></li></ul>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Each of the items in the list above has a required policy development and policy decisions. Equally, each is so intimately tied to the operation of the IANA function that it is impossible and ill-advised to insist there be a complete separate
between “policy” and “administration.” Going forward, I think we need to be careful to fit the solution to the problems. The IANA function is critical to the operation of the Internet. As technology changes, the details of its operation must change too.
From my perspective, there will be a mix of policy, technical, administrative and resource issues involved in these changes. We need a system that is transparent and accountable. We also need a system that is efficient and effective.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">I think that many, myself included, do not see how being part of ICANN<br>
and strict functionally separation are possible within ICANN's current<br>
configuration.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Can you identify specific instances where the current configuration has failed to operate properly and where the failure is due to lack of strict functional separation? (Also, I think there’s been pretty strong separation in place for
a long time, so I’m not sure how much more separation you have in mind.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">This may also be a big part of the expectations of global stakeholders.<br>
<br>
There is also the issue of ICANN being subject to US law. This remains a problem if ICANN plans to keep the administrative function after transition.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The question has already been asked and I’ll ask again. What is the specific problem about being subject to US law? As a general matter, rule of law is usually considered one of the U.S.’s very strongest qualities.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Steve<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>