[WP1] Frozen: AoC reviews into bylaws

Wed Jul 15 00:32:16 UTC 2015

Regarding review of new gTLD rounds:

In our 3-May draft proposal we have both post-batch AND period reviews:

1. We kept a review 1 year after each ‘batch’ just in case ICANN does another batch as we did in 2012.

2. We also have a periodic review at least once every five years, in case ICANN moves to continuous applications.

Regarding confidentiality, agree we need tighter text about how to determine what is truly confidential.

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.

From: <wp1-bounces at icann.org<mailto:wp1-bounces at icann.org>> on behalf of Avri Doria
Organization: Technicalities
Reply-To: Avri Doria
Date: Tuesday, July 14, 2015 at 8:13 PM
To: "wp1 at icann.org<mailto:wp1 at icann.org>"
Subject: Re: [WP1] Frozen: AoC reviews into bylaws

Hi,

Thanks for these.

I think something like P 3 has to be there.  Perhaps there is better
langauge.

Re page 6, good catch, could probably put it on timed cycle.  I expect
it will be a while before new gTLDs become uneventful.  All of the
periodic reviews can be canceled when appropriate.

On Page 7 I appreciate the idea of changing that AOC like text and would
be happy to work on a revision.

On the last one, page 8, we will still have to do a review for names, no
matter who holds the IANA functions contract.  ICANN community will
still be the caretaker of that contract.

thanks

avri

On 14-Jul-15 19:43, Steve Crocker wrote:
Jordan, et al,

Attached is my markup of the material on bringing AoC reviews into the
ICANN bylaws.  In brief, I think this is an excellent idea and I
strongly support it.  Further, I appreciate the modifications that
have already been made from the detailed language in the AoC to the
language proposed here.  That said, a bit more work is needed.

My comments in the marked up attachment cover the following (language
from the document highlighted followed by my comment):

On page 3:

     although the designation of sensitive / confidential should not
     be in ICANN’s sole discretion.

     I fully understand and appreciate the reason for inserting this
     caveat, but I don’t understand how this caveat helps.  When push
     comes to shove, ICANN Counsel is going to insist on adherence to
     the non-disclosure rules else the requested information won’t be
     forthcoming.  I suppose you can threaten to escalate but that’s
     not a productive path.

On page 6:

     The Board shall cause a review of ICANN’s execution of this
     commitment after any batched round of new gTLDs have been in
     operation for one year

     This language presumes the addition of new TLDs will be done in
     rounds similar to the current round of new gTLDs.  What happens if
     the process evolves toward continuous operation?

     Even if the system of rounds is maintained, it is likely the
     process will settle down.  Successive reviews will be
     progressively less meaningful.

On page 7:

     *Such existing policy requires that ICANN implement measures to
     maintain timely, unrestricted and public access to accurate and
     complete WHOIS information, including registrant, technical,
     billing, and administrative contact information.*
     ------------------------------------------------------------------------

     This is the language in the AoC that was inappropriate from the
     beginning and must not be continued.  The entire thrust of the
     effort kicked off by the Board in November 2012 was to examine the
     purpose and expectations of the registrant data system,
     particularly including the potential for tiered access, protection
     of registrant data, etc.

     I have no problem with keeping some form of review, but the
     language needs to be adjusted to match the potential for future
     systems that may emerge from the ongoing examination of the
     registration data.

     *its implementation meets **the **legitimate needs of law
     enforcement and promotes consumer trust.*

     This language puts Law Enforcement in the premier position with
     respect to evaluating the effectiveness of the registration data
     system.  Law Enforcement is indeed important, but not to the
     exclusion of all others.  “Promotes consumer trust” is too vague
     to cover all of the competing forces.

On page 8:

     The CWG-Stewardship has also proposed an IANA Function Review
     that should be added to the ICANN Bylaws, as a Fundamental Bylaw.

     What happens in the event the IANA function is moved away from
     ICANN?  It would be impossible to comply with this bylaw.  It
     seems to me a termination clause is needed.

Thanks,

Steve

On Jul 14, 2015, at 12:55 AM, Jordan Carter <jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz>
<mailto:jordan at internetnz.net.nz>> wrote:

Hi all

From Steve's team, please find attached the frozen document on the
incorporation of the AoC reviews into the bylaws, for discussion in
Paris.

Thanks for all the work done on this.

best,
Jordan

--
Jordan Carter

Chief Executive
*InternetNZ*

04 495 2118 (office) | +64 21 442 649 (mob)
jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz> <mailto:jordan at internetnz.net.nz>
Skype: jordancarter

/A better world through a better Internet /

<2015-07-12-DRAFT-PC2--6-2--AoC-Reviews.docx><2015-07-12-DRAFT-PC2--6-2--AoC-Reviews.pdf>_______________________________________________
WP1 mailing list
WP1 at icann.org<mailto:WP1 at icann.org> <mailto:WP1 at icann.org>
https://mm.icann.org/mailman/listinfo/wp1

_______________________________________________
WP1 mailing list
WP1 at icann.org<mailto:WP1 at icann.org>
https://mm.icann.org/mailman/listinfo/wp1

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
WP1 mailing list
WP1 at icann.org<mailto:WP1 at icann.org>
https://mm.icann.org/mailman/listinfo/wp1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/wp1/attachments/20150715/4eadef21/attachment-0001.html>