<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Mar 3, 2014, at 5:52 PM, Milton L Mueller <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="#0563C1" vlink="#954F72" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">Today IGP released an innovative proposal to resolve the 15-year controversy over the United States government�s special relationship to the Internet Corporation for Assigned Names and Numbers (ICANN).</span><a href="http://www.internetgovernance.org/wordpress/wp-content/uploads/ICANNreformglobalizingIANAfinal.pdf" style="font-size: 11pt; color: rgb(149, 79, 114);">http://www.internetgovernance.org/wordpress/wp-content/uploads/ICANNreformglobalizingIANAfinal.pdf</a></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><br></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">The proposal, which involves removing root zone management functions from ICANN and creating an independent and neutral private sector consortium to take them over, will be presented at the Singapore ICANN meeting March 21, and has also been submitted to the �NETMundial� Global Multistakeholder Meeting on the Future of Internet Governance in<span class="Apple-converted-space"> </span><em><span style="font-family: Calibri, sans-serif;">S�o<span class="Apple-converted-space"> </span></span></em>Paulo, Brazil, April 23 and 24.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">We propose four basic principles to guide the reform of the IANA functions: 1. Keep the IANA function clerical; separate it from policy; 2. Don�t internationalize political oversight: end it; 3. Align incentives to ensure the accuracy and security of root zone maintenance; 4. De-link globalization of the IANA function from broader ICANN policy process reforms. Even if there are quibbles about the details of the proposal, we look forward to gaining agreement on those principles, and are willing to entertain any proposals that embody them.</div></div></div></blockquote><br></div><div>Milton - </div><div> </div><div> Thank you (and Brenden :-) for submitting this proposal; if nothing else, its principle-based </div><div> assessment (and proposed solution) may lead to better understanding of some of the more </div><div> interesting aspects of the present IANA function arrangements...</div><div><br></div><div> I have a few comments and suggestions regarding the proposal; feel free to use or discard </div><div> as desired - </div><div><br></div><div>a) You describe the IANA functions in the context of the NTIA contract, but don't mention</div><div> the MOU between IAB/IETF and ICANN (RFC 2860) by which ICANN agrees to </div><div> perform IANA registry updates (for IETF protocols) in compliance with IETF RFCs;</div><div> further noting that assignment of domain names and the assignment of IP address </div><div> blocks are also subject to "policy issues" for which ICANN may follow its adopted </div><div> policy so long as it does not prevent RFC compliance (less the IETF terminate)</div><div><br></div><div> Given that the IETF defines the protocols which create the actual registry spaces</div><div> (DNS, IPv4, IPv6) for the general purpose identifiers that are being administered, </div><div> it might be worth seeking similar acknowledgement from the IAB/IETF of any new </div><div> arrangements for clerical administration of the DNS identifier space. Some may</div><div> argue that formal recognition isn't needed for various reasons, but even nominal </div><div> acknowledgment might help prevent potential confusion in future DNSA / IETF </div><div> relations (e.g. related to DNS protocol & technical requirement changes) as well</div><div> as providing a framework for those entries in the DNS root zone which are purely</div><div> present due to technical requirements (e.g. .arpa)</div><div><br></div><div>b) Your proposal suggests that "the IANA functions related to protocol parameters </div><div> would be moved to the IETF", where believe it might be more appropriate to </div><div> suggest instead that "the IANA functions related to protocol parameters should</div><div> be performed per authority of the IETF (who may perform them directly or instead</div><div> contract them to a third-party as they choose)" The IETF may not necessarily </div><div> have the desire or capacity to perform these tasks directly, so it might be better </div><div> for the proposal to simply note the authority by which they will be performed.</div><div><br></div><div>c) The proposal also suggests that "the IP address�-related functions would be retained</div><div> by ICANN until such time as new global policies regarding their disposition could </div><div> be developed"; that is interesting considering that the address aspects of the IANA</div><div> functions are something today which is very clearly defined, both by ICANN Address </div><div> Supporting Organization (ASO) MoU and IETF RFC 7020. It might be best to simply </div><div> note in a parallel fashion per above that "The IANA functions related to IP addresses</div><div> should be performed in a manner agreed by the IETF and the Internet addressing </div><div> community." rather than distract from the real DNSA-focus of your proposal. </div><div><br></div><div> d) From points b and c above, it is fairly clear that it would be useful for the IETF (at </div><div> some point) to set some broad guidelines for how they wish to handle administration</div><div> of general-purpose identifier registries, so that if we ever get a new protocol (or new </div><div> version of an existing protocol) which has globally-unique identifiers for general</div><div> purpose consumption, we'd at least have some guidelines that we'd all know would </div><div> apply such as: authority for general purpose identifier registries should only be </div><div> delegated to parties which the IETF believes are reasonably representative of the </div><div> communities dependent upon the registry, that do policy development in a manner</div><div> open to all interested parties and via transparent decision making processes, etc. </div><div> This also may not be a matter directly for inclusion in your proposal, but still worth</div><div> considering as may imply a source for some of the criteria for both the DNSA and </div><div> any party performing policy development activities for the general-purpose DNS </div><div> registry.</div><div><br></div><div>e) As a general comment it would be worth noting the irony of the proposal, in that </div><div> it finishes the inversion of ICANN which started with the absorption of the original</div><div> DNSO into ICANN. ICANN was intended to be the administrative coordination </div><div> body for all of the IETF registries (protocol numbers, IP address, DNS names) and </div><div> was to make use of external bodies for primary policy development functions. Per</div><div> your proposal, DNS policy development is finally recognized as ICANN's "reason </div><div> for being"; a very significant task which deserves a body dedicated to that mission.</div><div><br></div><div>Thanks again! Feedback on the above thoughts would be welcome.</div><div>/John</div><div><br></div><div>Disclaimers: Read carefully - My views alone. In particular, while I have some </div><div> awareness of the various organizations mentioned in this message, </div><div> that does not imply in any manner any overlap between them and </div><div> my particular hallucinations on how things might work, and in fact, </div><div> any proposal following my suggestions may be become less (rather </div><div> than more) credible as a result... caveat emptor. No refunds. </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div></body></html>