<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
Regarding review of new gTLD rounds:</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
In our 3-May draft proposal we have both post-batch AND period reviews:</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<br>
</div>
<blockquote style="margin:0 0 0 40px; border:none; padding:0px;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
1. We kept a review 1 year after each ‘batch’ just in case ICANN does another batch as we did in 2012.</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
2. We also have a periodic review at least once every five years, in case ICANN moves to continuous applications.</div>
<div><br>
</div>
</blockquote>
<div>Regarding confidentiality, agree we need tighter text about how to determine what is truly confidential.</div>
<div><br>
</div>
<div>Regarding Whois/Directory Services Review: This review, as written, is a current obligation of ICANN under the AoC. Stress Test 14 provoked bringing AoC reviews into the bylaws, and we did so without significantly changing the commitments or parameters
of the AoC reviews. </div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px;">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:wp1-bounces@icann.org">wp1-bounces@icann.org</a>> on behalf of Avri Doria<br>
<span style="font-weight:bold">Organization: </span>Technicalities<br>
<span style="font-weight:bold">Reply-To: </span>Avri Doria<br>
<span style="font-weight:bold">Date: </span>Tuesday, July 14, 2015 at 8:13 PM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:wp1@icann.org">wp1@icann.org</a>"<br>
<span style="font-weight:bold">Subject: </span>Re: [WP1] Frozen: AoC reviews into bylaws<br>
</div>
<div><br>
</div>
<div>
<div>
<div>Hi,</div>
<div><br>
</div>
<div>Thanks for these.</div>
<div><br>
</div>
<div>I think something like P 3 has to be there. Perhaps there is better</div>
<div>langauge. </div>
<div><br>
</div>
<div>Re page 6, good catch, could probably put it on timed cycle. I expect</div>
<div>it will be a while before new gTLDs become uneventful. All of the</div>
<div>periodic reviews can be canceled when appropriate.</div>
<div><br>
</div>
<div>On Page 7 I appreciate the idea of changing that AOC like text and would</div>
<div>be happy to work on a revision.</div>
<div><br>
</div>
<div>On the last one, page 8, we will still have to do a review for names, no</div>
<div>matter who holds the IANA functions contract. ICANN community will</div>
<div>still be the caretaker of that contract. </div>
<div><br>
</div>
<div>thanks</div>
<div><br>
</div>
<div>avri</div>
<div><br>
</div>
<div><br>
</div>
<div>On 14-Jul-15 19:43, Steve Crocker wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Jordan, et al,</div>
<div><br>
</div>
<div>Attached is my markup of the material on bringing AoC reviews into the</div>
<div>ICANN bylaws. In brief, I think this is an excellent idea and I</div>
<div>strongly support it. Further, I appreciate the modifications that</div>
<div>have already been made from the detailed language in the AoC to the</div>
<div>language proposed here. That said, a bit more work is needed.</div>
<div><br>
</div>
<div>My comments in the marked up attachment cover the following (language</div>
<div>from the document highlighted followed by my comment):</div>
<div><br>
</div>
<div>On page 3:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> although the designation of sensitive / confidential should not</div>
<div> be in ICANN’s sole discretion.</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div> I fully understand and appreciate the reason for inserting this</div>
<div> caveat, but I don’t understand how this caveat helps. When push</div>
<div> comes to shove, ICANN Counsel is going to insist on adherence to</div>
<div> the non-disclosure rules else the requested information won’t be</div>
<div> forthcoming. I suppose you can threaten to escalate but that’s</div>
<div> not a productive path.</div>
<div><br>
</div>
<div><br>
</div>
<div>On page 6:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> The Board shall cause a review of ICANN’s execution of this</div>
<div> commitment after any batched round of new gTLDs have been in</div>
<div> operation for one year</div>
</blockquote>
<div><br>
</div>
<div> This language presumes the addition of new TLDs will be done in</div>
<div> rounds similar to the current round of new gTLDs. What happens if</div>
<div> the process evolves toward continuous operation?</div>
<div><br>
</div>
<div> Even if the system of rounds is maintained, it is likely the</div>
<div> process will settle down. Successive reviews will be</div>
<div> progressively less meaningful. </div>
<div><br>
</div>
<div><br>
</div>
<div>On page 7:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> *Such existing policy requires that ICANN implement measures to</div>
<div> maintain timely, unrestricted and public access to accurate and</div>
<div> complete WHOIS information, including registrant, technical,</div>
<div> billing, and administrative contact information.* </div>
</blockquote>
<div> ------------------------------------------------------------------------</div>
<div><br>
</div>
<div> This is the language in the AoC that was inappropriate from the</div>
<div> beginning and must not be continued. The entire thrust of the</div>
<div> effort kicked off by the Board in November 2012 was to examine the</div>
<div> purpose and expectations of the registrant data system,</div>
<div> particularly including the potential for tiered access, protection</div>
<div> of registrant data, etc.</div>
<div><br>
</div>
<div> I have no problem with keeping some form of review, but the</div>
<div> language needs to be adjusted to match the potential for future</div>
<div> systems that may emerge from the ongoing examination of the</div>
<div> registration data.</div>
<div><br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> *its implementation meets **the **legitimate needs of law</div>
<div> enforcement and promotes consumer trust.*</div>
</blockquote>
<div><br>
</div>
<div> This language puts Law Enforcement in the premier position with</div>
<div> respect to evaluating the effectiveness of the registration data</div>
<div> system. Law Enforcement is indeed important, but not to the</div>
<div> exclusion of all others. “Promotes consumer trust” is too vague</div>
<div> to cover all of the competing forces.</div>
<div><br>
</div>
<div>On page 8:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> The CWG-Stewardship has also proposed an IANA Function Review</div>
<div> that should be added to the ICANN Bylaws, as a Fundamental Bylaw. </div>
</blockquote>
<div><br>
</div>
<div> What happens in the event the IANA function is moved away from</div>
<div> ICANN? It would be impossible to comply with this bylaw. It</div>
<div> seems to me a termination clause is needed.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Jul 14, 2015, at 12:55 AM, Jordan Carter <<a href="mailto:jordan@internetnz.net.nz">jordan@internetnz.net.nz</a></div>
<div><<a href="mailto:jordan@internetnz.net.nz>">mailto:jordan@internetnz.net.nz></a>> wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Hi all</div>
<div><br>
</div>
<div>From Steve's team, please find attached the frozen document on the</div>
<div>incorporation of the AoC reviews into the bylaws, for discussion in</div>
<div>Paris.</div>
<div><br>
</div>
<div>Thanks for all the work done on this.</div>
<div><br>
</div>
<div>best,</div>
<div>Jordan</div>
<div><br>
</div>
<div>-- </div>
<div>Jordan Carter</div>
<div><br>
</div>
<div>Chief Executive</div>
<div>*InternetNZ*</div>
<div><br>
</div>
<div>04 495 2118 (office) | +64 21 442 649 (mob)</div>
<div><a href="mailto:jordan@internetnz.net.nz">jordan@internetnz.net.nz</a> <<a href="mailto:jordan@internetnz.net.nz">mailto:jordan@internetnz.net.nz</a>></div>
<div>Skype: jordancarter</div>
<div><br>
</div>
<div>/A better world through a better Internet /</div>
<div><br>
</div>
<div><2015-07-12-DRAFT-PC2--6-2--AoC-Reviews.docx><2015-07-12-DRAFT-PC2--6-2--AoC-Reviews.pdf>_______________________________________________</div>
<div>WP1 mailing list</div>
<div><a href="mailto:WP1@icann.org">WP1@icann.org</a> <<a href="mailto:WP1@icann.org">mailto:WP1@icann.org</a>></div>
<div><a href="https://mm.icann.org/mailman/listinfo/wp1">https://mm.icann.org/mailman/listinfo/wp1</a></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>WP1 mailing list</div>
<div><a href="mailto:WP1@icann.org">WP1@icann.org</a></div>
<div><a href="https://mm.icann.org/mailman/listinfo/wp1">https://mm.icann.org/mailman/listinfo/wp1</a></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>---</div>
<div>This email has been checked for viruses by Avast antivirus software.</div>
<div><a href="https://www.avast.com/antivirus">https://www.avast.com/antivirus</a></div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>WP1 mailing list</div>
<div><a href="mailto:WP1@icann.org">WP1@icann.org</a></div>
<div><a href="https://mm.icann.org/mailman/listinfo/wp1">https://mm.icann.org/mailman/listinfo/wp1</a></div>
<div><br>
</div>
</div>
</div>
</span>
</body>
</html>