August 2016 - ALAC - lists.icann.org

Re: [ALAC] [ALAC-Announce] Call for Volunteers: Advisory Panel on gTLD Marketplace Health Index
by Olivier MJ Crepin-Leblond Aug. 26, 2016

Aug. 26, 2016

Hello all, following up on last week's ALAC call, I have hastily put together a first draft on: https://community.icann.org/x/cAubAw Please review and comment as soon as possible. I also note that the Public Consultation asks for volunteers to join an Advisory Panel about the topic. Please consider joining it. It appears that the way to do this is to join a mailing list - details given on the page. Kindest regards, Olivier On 23/12/2015 01:15, ICANN At-Large Staff wrote: > Dear All, > > ICANN is calling for community volunteers to participate in the > Advisory Panel on gTLD Marketplace Health Index. This Advisory Panel > will review the proposed KPIs in the preliminary proposal of gTLD > Marketplace Health Index > <https://www.icann.org/en/system/files/files/gtld-marketplace-health-index-p…>, > as well as the suggested potential updates in light of the public > comment > <https://www.icann.org/public-comments/gtld-marketplace-health-2015-11-17-en> on > this preliminary proposal. The Advisory Panel will also be asked to > assist ICANN in finalizing the list of KPIs and in setting proposed > benchmarks for measuring the health of the global gTLD marketplace. > As an FYI, the ALAC has responded to the public comment on the gTLD > Marketplace Health Index Proposal and submitted a > Statement: https://newatlarge.icann.org/advice_statements/9745. > > At-Large members interested in this topic are welcome to join the > Advisory Panel. Experience in the global domain name industry, > economics, and data analytics will be particularly helpful to the > Advisory Panel’s work. Perspectives from diverse regions and > backgrounds will help ensure that the gTLD Marketplace Health Index > presents a holistic view of the global domain name marketplace. > > If you are interested in volunteering for the Advisory Panel,* please > email amy.bivins(a)icann.org <mailto:amy.bivins@icann.org> by 22 January > 2016*. > > Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie > Peregrine, Terri Agnew and Yesim Nazlar > > ICANN Policy Staff in support of the At-Large Community > > E-mail: staff(a)atlarge.icann.org <mailto:staff@atlarge.icann.org> > > Facebook: www.facebook.com/icann > <https://www.facebook.com/icannatlarge>atlarge > <https://www.facebook.com/icannatlarge> > > Twitter: @ <https://twitter.com/ICANNAtLarge>ICANNAtLarge > <https://twitter.com/ICANNAtLarge> > > unknown.png > > > > _______________________________________________ > ALAC-Announce mailing list > ALAC-Announce(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac-announce > > At-Large Official Site: http://www.atlarge.icann.org

1 0

LAST CALL for Membership of 2017 BCEC and BMSPC
by ICANN At-Large Staff Aug. 22, 2016

Aug. 22, 2016

Dear All, Please note that the deadline for applying to the Board Member Selection Process Committee (BMSPC) and the Board Candidate Evaluation Committee (BCEC), the two groups that will be responsible for moving forward the process of selecting the ICANN Board Member to be seated at the October 2017 Annual General Meeting, is 23:59 UTC on Tuesday, 23 August 2016. If you are interested, or if you wish to nominate someone else, please send a note to At-Large staff at staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org%3c> specifying which committee(s) the application or nomination is for and citing any applicable experience by the deadline. A record of all applications and nominations will be posted to either the BMSPC Membership Selection 2017 Workspace (see: https://community.icann.org/x/oAysAw) or the BCEC Membership Selection 2017 Workspace (see: https://community.icann.org/x/hgysAw) as appropriate. The full details of the call for membership is below. Kind regards, Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie Peregrine, Terri Agnew and Yeşim Nazlar ICANN Policy Staff in support of the At-Large Community E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge> [unknown.png] From: ICANN At-Large Staff Sent: Monday, August 15, 2016 9:02 PM To: 'alac(a)atlarge-lists.icann.org' <alac(a)atlarge-lists.icann.org> Cc: ICANN At-Large Staff (staff(a)atlarge.icann.org) <staff(a)atlarge.icann.org>; Alan Greenberg (alan.greenberg(a)mcgill.ca) <alan.greenberg(a)mcgill.ca> Subject: Call for Membership of 2017 BCEC and BMSPC Dear All, To prepare for the selection of the Board Member selected by At-Large to be seated at the October 2017 Annual General Meeting, Alan Greenberg, the Chair of the ALAC, has asked staff to make an immediate call for members of the two groups who will be responsible for moving the process forward. According to the ALAC Rules of Procedure (2016) (see: http://tinyurl.com/ALAC-RoP-2016-07) the two groups are the 2017 Board Member Selection Process Committee (BMSPC) and the 2017 Board Candidate Evaluation Committee (BCEC). Please see ALAC Rules of Procedure (2016-07) Section D.19 - Procedure for Making the Selection to fill Seat 15 on the ICANN Board. The deadline for applying to be members of both groups is 23:59 UTC on Tuesday, 23 August 2016. If you are interested, or if you wish to nominate someone else, please send a note to At-Large staff at staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org%3c> specifying which committee(s) the application or nomination is for and citing any applicable experience by the deadline. A record of all applications and nominations will be posted to either the BMSPC Membership Selection 2017 Workspace (see: https://community.icann.org/x/oAysAw) or the BCEC Membership Selection 2017 Workspace (see: https://community.icann.org/x/hgysAw) as appropriate. The full At-Large Board Member 2017 Selection Workspace is available at: https://community.icann.org/x/CAWsAw) The RALO leadership is requested to send a list of their RALO's supported candidates for each group to the Chair of the ALAC by 23:59 UTC Tuesday, 30 August 2016. The ALAC will name the final membership soon after. The details of the two groups are: 1) Board Member Selection Process Committee (BMSPC) According to Article 19.2 of the ALAC Rules of Procedure (2016): "The ALAC shall name a Board Member Selection Process Committee (BMSPC) which shall oversee the entire selection process including the election culminating the process but excluding those responsibilities specifically retained by the ALAC or given to the Board Candidate Evaluation Committee. The composition of the BMSPC will be regionally balanced and the committee will be populated with two representatives of each region selected by both the ALAC and the RALOs. For each region, one Alternate member will be selected who can replace a member from the same region who for whatever reason is not able to fully participate and such replacement will be at the sole discretion of the BMSPC Chair in accordance with BMSPC guidelines. The ALAC shall name a chair of the BMSPC." The group is open to both ALAC Members and to At-Large community members and to RALO Leaders. However, the membership should include members of the community with significant experience from the 2010 or 2014 Board Director selected by At-Large process. English will be the working language of this group. The group must be regionally balanced, with two representatives from each of the five RALOs. Each RALO will also select an Alternate member in the event one of the original members must be replaced. Please note that no member of the BMSPC may submit an Expression of Interest (EOI) for the position of the Board Director selected by At-Large. The ALAC will select the Chair of the BMSPC. The first meeting of the BMSPC will be scheduled for late August or early September. 2) Board Candidate Evaluation Committee (BCEC) The new ALAC Rules of Procedures state the following on the composition and task of the BCEC: "19.3 The ALAC shall name a Board Candidate Evaluation Committee (BCEC) to compile an initial slate of candidates for election to Seat 15. A new BCEC consisting of two delegates selected by each of the RALOs plus a chair selected by the ALAC will be convened for each Board seat selection process. Each RALO shall also select an Alternate member who can replace a member from the same region who for whatever reason is not able to fully participate and such replacement will be at the sole discretion of the BCEC Chair in accordance with BCEC guidelines" "19.4 The task of the BCEC is to identify applicants who would each make an excellent Board Director. [19.4.1] Applicant selected by the BCEC must meet the criteria specified in the ICANN Bylaws Article VI, Section 3 ( http://www.icann.org/en/about/governance/bylaws#VI-3) These criteria include but are not limited to being: a) accomplished persons of integrity, objectivity, and intelligence, with reputations for sound judgment and open minds, and a demonstrated capacity for thoughtful group decision-making; and b) persons with an understanding of ICANN's mission and the potential impact of ICANN decisions on the global Internet community, and committed to the success of ICANN. Moreover, the Director selected by the At-Large Community must understand the mission of At-Large and the needs of the global community of Internet end users." "19.5 No member of the electorate (Paragraph 19.10) may simultaneously serve as a member of the BCEC." According to 19.5, members of the electorate (i.e., members of the ALAC and RALO Chairs who will be serving in 2017) may not be BCEC members. The group must be regionally balanced, with two representatives from each of the five RALOs. Each RALO will also select an Alternate member in the event one of the original members must be replaced. Additionally, no member of the BCEC may submit an Expression of Interest (EOI) for the position of the Board Director selected by At-Large. Please note that experience on the 2010 or 2014 BCEC and/or on the ICANN Nominating Committee would be highly desired. English will be the working language of this group. The ALAC will select the Chair of the BCEC. The first meeting of the BCEC will be scheduled for late August or early September. Regards, Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie Peregrine, Terri Agnew and Yeşim Nazlar ICANN Policy Staff in support of the At-Large Community E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge> [unknown.png]

1 0

Re: [ALAC] [ALAC-Announce] CCWG Accountability Webinar | Tuesday 23 August 2016 at 20:30 UTC
by Olivier MJ Crepin-Leblond Aug. 22, 2016

Aug. 22, 2016

Hello all, what is this Webinar about? I note that the agenda is not updated hence I have no clue what this is for. Is this about cost control mechanisms on how to control the cost expenditures of CCWG Accountability Work Stream 2 in which case I don't know how this is of concern to all ALAC members, or is it about new cost control mechanisms in ICANN for future ICANN budgets, in which case this has the potential to greatly affect At-Large as our budget seems to always be complained about by other parts of ICANN? Kindest regards, Olivier On 22/08/2016 09:23, ICANN At-Large Staff wrote: > > Dear all, > > Please find hereafter the invitation to the *CCWG Accountability > webinar on the Proposed Cost Control Mechanisms *scheduled on*Tuesday > 23 August 2016 at 20:30 UTC. * > > For other times:*http://tinyurl.com/z6rnkrz* > > Presenters: > > * Thomas Rickert - Co-Chair CCWG-Accountability > * Xavier Calvez - ICANN CFO > * Bernard Turcotte - Manager ICANN PCST/ ICANN Staff Support to the > CCWG-Accountability > > > Presentation Materials will be: > > * Budget Ownership -- Xavier Calvez > * Legal Cost Control Mechanisms in the CCWG-Accountability - Thomas > Rickert > > > /French and Spanish interpretation will be confirmed shortly./ > > > Adobe connect: *http://icann.adobeconnect.com/alac* > > > The agenda and call details are available here: > https://community.icann.org/x/iBCsAw > > Dial-in numbers: <http://adigo.com/icann/>http://adigo.com/icann/ > <http://adigo.com/icann/%C2%A0> > Conference ID’s > English: 1638 > > Spanish: 1738 (TBC) > > French: 1838 (TBC) > > > If you require a dial-out please contact At-Large staff > at: staff(a)atlarge.icann.org > <applewebdata://06798D17-FF07-43D5-9BBD-585739960399/staff@atlarge.icann.org> > > > Thank you. > > Regards, > > Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie > Peregrine, Terri Agnew and Yeşim Nazlar > > ICANN Policy Staff in support of the At-Large Community > > E-mail: staff(a)atlarge.icann.org <mailto:staff@atlarge.icann.org> > > Website: atlarge.icann.org <https://atlarge.icann.org/> > > Facebook: www.facebook.com/icann > <https://www.facebook.com/icannatlarge>atlarge > <https://www.facebook.com/icannatlarge> > > Twitter: @ <https://twitter.com/ICANNAtLarge>ICANNAtLarge > <https://twitter.com/ICANNAtLarge> > > unknown.png > > /One World, One Internet/ > > > > > _______________________________________________ > ALAC-Announce mailing list > ALAC-Announce(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac-announce > > At-Large Official Site: http://www.atlarge.icann.org

2 1

Motion to amend Rules of Procedure
by Alan Greenberg Aug. 22, 2016

Aug. 22, 2016

In Helsinki, the ALAC approved a number of changes to its Rules of Procedure (RoP) related to the selection of the At-Large Director (ICANN Board Seat 15). Due to lack of time, a number of other changes were not discussed or approved. These we discussed during the ALAC teleconference on 26 July. Most of these changes elicited no negative comments but one, a formalization of current ALAC Leadership Team (ALT) practices, did result in a number of comments. Also discussed in Helsinki and briefly on the July ALA teleconference were changes that are required to support the ICANN Empowered Community (EC). The EC will come into being when and if the ICANN Bylaws adopted by the Board on 27 May go into effect. This will happen when and if the IANA transition is completed with the expiration of the IANA Functions Contract between the NTIA and ICANN. The NTIA announced this week that it intended to let the contract expire at the end of September. Presuming this process is not halted due to some extraordinary action within the US Government, the contract will expire on 30 September, the new Bylaws will be triggered and the EC will exist, and the ALAC must be able to function within it. As discussed, I convened a small group composed of those within our community most knowledgeable about the EC and its accountability measures. This group was comprised of the five ALAC Members of the CCWG-Accountability (me, Tijani, Cheryl, Sébastien and Leon) as well as Seun and Olivier, both of who devoted much time to participating in the CCWG and understanding all of the issues. It was agreed that we would use a minimalist approach to ensure that the ALAC could fulfill its duties. It may be that at some point in the future we revisit these rules, but for the moment, and given the tight time lines, a simple approach was the wisest path to follow. The group did discuss whether the Chair or someone else should represent the ALAC on the EC. It was felt that the default should be the Chair because: a) there is no real power associated with the position; b) there is are already detailed measures in the RoP to control the accountability of the Chair, and to remove the Chair if there is some gross misuse of the EC power (as implied in the CCWG_ACCT recommendations) The RoP revision includes three sets of changes. 1. The revisions previously presented for the Helsinki meeting, deferred, and then discussed on 26 July. The section on ALT practices has been largely re-written to address the issues raised. In particular: a) there is no longer any reference to past ALAC Chairs, but a more generic reference to other who might be invited to participate; b) there is no longer a reference to guests invited at the "sole discretion" of the Chair - this decision like all other ALT decision will be made collegially; c) it is clarified for the purposes of full transparency, that any ALT decisions are made solely by the five regional representatives and not by the Liaisons or other invited people. 2. Two small changes to the Director selection section to address a possible case of a tied vote that had been accidentally omitted, and to clarify that the BMSPC is composed of ten regional representatives plus a Chair (it previously was not clear if the Chair was one of the ten). 3. The changes associate with the EC. According to the RoP section 13.1.1, a motion to amend the rules must be made 21 days in advance. Accordingly, I am opening this discussion of the proposed RoP Revision. Subject to the discussion, a vote of the ALAC will be taken after the 21 day period elapses (09 September). I am proposing that we adopt these changes in a single vote. However, if any ALAC Member wishes that we segregate out particular changes for a separate vote, that will be done (presuming each package of revisions can stand on its own). I hereby make the following motion and ask that another ALAC Member second it. Whereas the At-Large Advisory Committee is currently operating under Rules of Procedure (RoP) approved on 20 June 2016; Whereas a number of changes to these (RoP) have been recommended to correct errors, clarify specific rules, enhance transparency and implement the ICANN Empowered Community; Therefore; The ALAC adopts the attached revisions to the ALAC Rules of Procedure. ----------------------------- Also attached is a detailed log describing each change and the rationale for it. This motion and the final RoP adopted by the ALAC may be amended as agreed to by the ALAC prior to final adoption. Final adoption will require a super-majority (2/3) vote of the ALAC.

6 6

Re: [ALAC] Motion to amend Rules of Procedure
by Alan Greenberg Aug. 19, 2016

Aug. 19, 2016

Perhaps a matter of style. 23.2 established (and defines) the EC, and 23.3 establishes that the ALAC is part of it (both with the changes as suggested by Tijani). At 18/08/2016 10:50 PM, Seun Ojedeji wrote: >Thanks, On a quick look the edit looks >good. Though I don't see the need for session >23.2 and 23.3 as they do not add anything >significant to purpose of section 23 which I >believe is to indicate that the EC will only be >active at a later time defined in section 23.1 > >Regards > >Sent from my LG G4 >Kindly excuse brevity and typos > >On 18 Aug 2016 05:59, "Alan Greenberg" ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >In Helsinki, the ALAC approved a number of >changes to its Rules of Procedure (RoP) related >to the selection of the At-Large Director (ICANN >Board Seat 15). Due to lack of time, a number of >other changes were not discussed or approved. >These we discussed during the ALAC >teleconference on 26 July. Most of these changes >elicited no negative comments but one, a >formalization of current ALAC Leadership Team >(ALT) practices, did result in a number of comments. > >Also discussed in Helsinki and briefly on the >July ALA teleconference were changes that are >required to support the ICANN Empowered >Community (EC). The EC will come into being when >and if the ICANN Bylaws adopted by the Board on >27 May go into effect. This will happen when and >if the IANA transition is completed with the >expiration of the IANA Functions Contract >between the NTIA and ICANN. The NTIA announced >this week that it intended to let the contract >expire at the end of September. Presuming this >process is not halted due to some extraordinary >action within the US Government, the contract >will expire on 30 September, the new Bylaws will >be triggered and the EC will exist, and the ALAC >must be able to function within it. > >As discussed, I convened a small group composed >of those within our community most knowledgeable >about the EC and its accountability measures. >This group was comprised of the five ALAC >Members of the CCWG-Accountability (me, Tijani, >Cheryl, SÃ©bastien and Leon) as well as Seun and >Olivier, both of who devoted much time to >participating in the CCWG and understanding all >of the issues. It was agreed that we would use a >minimalist approach to ensure that the ALAC >could fulfill its duties. It may be that at some >point in the future we revisit these rules, but >for the moment, and given the tight time lines, >a simple approach was the wisest path to follow. > >The group did discuss whether the Chair or >someone else should represent the ALAC on the >EC. It was felt that the default should be the >Chair because: a) there is no real power >associated with the position; b) there is are >already detailed measures in the RoP to control >the accountability of the Chair, and to remove >the Chair if there is some gross misuse of the >EC power (as implied in the CCWG_ACCT recommendations) > >The RoP revision includes three sets of changes. > >1. The revisions previously presented for the >Helsinki meeting, deferred, and then discussed >on 26 July. The section on ALT practices has >been largely re-written to address the issues >raised. In particular: a) there is no longer any >reference to past ALAC Chairs, but a more >generic reference to other who might be invited >to participate; b) there is no longer a >reference to guests invited at the "sole >discretion" of the Chair - this decision like >all other ALT decision will be made collegially; >c) it is clarified for the purposes of full >transparency, that any ALT decisions are made >solely by the five regional representatives and >not by the Liaisons or other invited people. > >2. Two small changes to the Director selection >section to address a possible case of a tied >vote that had been accidentally omitted, and to >clarify that the BMSPC is composed of ten >regional representatives plus a Chair (it >previously was not clear if the Chair was one of the ten). > >3. The changes associate with the EC. > >According to the RoP section 13.1.1, a motion to >amend the rules must be made 21 days in advance. >Accordingly, I am opening this discussion of the >proposed RoP Revision. Subject to the >discussion, a vote of the ALAC will be taken >after the 21 day period elapses (09 September). > >I am proposing that we adopt these changes in a >single vote. However, if any ALAC Member wishes >that we segregate out particular changes for a >separate vote, that will be done (presuming each >package of revisions can stand on its own). > > >I hereby make the following motion and ask that another ALAC Member second it. > >Whereas the At-Large Advisory Committee is >currently operating under Rules of Procedure (RoP) approved on 20 June 2016; > >Whereas a number of changes to these (RoP) have >been recommended to correct errors, clarify >specific rules, enhance transparency and >implement the ICANN Empowered Community; > >Therefore; > >The ALAC adopts the attached revisions to the ALAC Rules of Procedure. > >----------------------------- >Also attached is a detailed log describing each >change and the rationale for it. > >This motion and the final RoP adopted by the >ALAC may be amended as agreed to by the ALAC >prior to final adoption. Final adoption will >require a super-majority (2/3) vote of the ALAC. > > > > >_______________________________________________ >ALAC mailing list ><mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org >https://atlarge-lists.icann.org/mailman/listinfo/alac > >At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org >ALAC Working Wiki: ><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…

2 1

Call for Nominations for ALAC Chair
by ICANN At-Large Staff Aug. 18, 2016

Aug. 18, 2016

Dear All, The At-Large Advisory Committee (ALAC) Rules of Procedure Section 17 (RoP - http://tinyurl.com/ALAC-RoP-2016-07) call for the ALAC Chair to be elected for one year, but subject to certain conditions, may automatically be renewed for one additional year. As Alan Greenberg was elected to serve as Chair for 2014-15, and was automatically renewed for 2015-16, this year there must be a new election. for ALAC Chair for the 2016-2017 ICANN year. The requirements and responsibilities of the Chair are listed in Section 5 of the RoP. The Chair must make a major time commitment in the order of 20-40 hours per week, and at times significantly more. Recent Chairs have regularly participated in all ALAC meetings, most ALAC Working Groups and Sub-Committee meetings, many RALO meetings as well as participated actively in ICANN policy Working Groups. ICANN meetings for Chairs are typically at least one day longer than for other ALAC Members. Nominations are now open for individuals to serve as the Chair of the ALAC. Nominations may be made by any current ALAC Member. Nominees need not be an ALAC Member at the time of the nomination, but must have a reasonable expectation of being an ALAC Member after the completion of the upcoming Hyderabad ICANN Meeting. Nominations will close on 31 August 2016 at 23:59 UTC. Nominations need not be seconded, but it is an ALAC tradition that others may second the nomination as a show of agreement with the nomination. Nominations other than self-nominations must be accepted within seven days after the close of nominations. Acceptance should be sent to the alac(a)atlarge-lists.icann.org<mailto:alac@atlarge-lists.icann.org>. Nominees without access to that list should send their acceptance to staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org>. According to the ALAC RoP, following the nominations/acceptance period, a Selection Summary will be posted giving the details of the following process. The selection of the four other ALAC Leadership Team members will be initiated once the selection of the Chair is completed. The At-Large ALAC and RALO Elections, Selections and Appointments - 2016 Workspace <see https://community.icann.org/x/qzKAAw> has additional details and Staff will post all information related to this selection. Kind regards, Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie Peregrine, Terri Agnew and Yeşim Nazlar ICANN Policy Staff in support of the At-Large Community E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge> [unknown.png]

3 2

Registration for Hyderabad meeting
by Alan Greenberg Aug. 17, 2016

Aug. 17, 2016

Note that unlike the Panama meeting that became Helsinki, the San Juan meeting is still in the list of ICANN meeting registrations, and if you already registered for Panama, you need to go through the process again for Hyderabad - https://registration.icann.org/. Alan

1 0

IANA Transition approved
by Alan Greenberg Aug. 16, 2016

Aug. 16, 2016

https://www.ntia.doc.gov/other-publication/2016/letter-icann-ceo-marby-rega… Pending obstacles (such as the recent CRUZ letter (https://cruz.senate.gov/files/documents/Letters/20160812_DOJ-ICANNLetter.pdf) the IANA transition has been approved.

2 1

Call for Membership of 2017 BCEC and BMSPC
by ICANN At-Large Staff Aug. 16, 2016

Aug. 16, 2016

Dear All, To prepare for the selection of the Board Member selected by At-Large to be seated at the October 2017 Annual General Meeting, Alan Greenberg, the Chair of the ALAC, has asked staff to make an immediate call for members of the two groups who will be responsible for moving the process forward. According to the ALAC Rules of Procedure (2016) (see: http://tinyurl.com/ALAC-RoP-2016-07) the two groups are the 2017 Board Member Selection Process Committee (BMSPC) and the 2017 Board Candidate Evaluation Committee (BCEC). Please see ALAC Rules of Procedure (2016-07) Section D.19 - Procedure for Making the Selection to fill Seat 15 on the ICANN Board. The deadline for applying to be members of both groups is 23:59 UTC on Tuesday, 23 August 2016. If you are interested, or if you wish to nominate someone else, please send a note to At-Large staff at staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org%3c> specifying which committee(s) the application or nomination is for and citing any applicable experience by the deadline. A record of all applications and nominations will be posted to either the BMSPC Membership Selection 2017 Workspace (see: https://community.icann.org/x/oAysAw) or the BCEC Membership Selection 2017 Workspace (see: https://community.icann.org/x/hgysAw) as appropriate. The full At-Large Board Member 2017 Selection Workspace is available at: https://community.icann.org/x/CAWsAw) The RALO leadership is requested to send a list of their RALO's supported candidates for each group to the Chair of the ALAC by 23:59 UTC Tuesday, 30 August 2016. The ALAC will name the final membership soon after. The details of the two groups are: 1) Board Member Selection Process Committee (BMSPC) According to Article 19.2 of the ALAC Rules of Procedure (2016): "The ALAC shall name a Board Member Selection Process Committee (BMSPC) which shall oversee the entire selection process including the election culminating the process but excluding those responsibilities specifically retained by the ALAC or given to the Board Candidate Evaluation Committee. The composition of the BMSPC will be regionally balanced and the committee will be populated with two representatives of each region selected by both the ALAC and the RALOs. For each region, one Alternate member will be selected who can replace a member from the same region who for whatever reason is not able to fully participate and such replacement will be at the sole discretion of the BMSPC Chair in accordance with BMSPC guidelines. The ALAC shall name a chair of the BMSPC." The group is open to both ALAC Members and to At-Large community members and to RALO Leaders. However, the membership should include members of the community with significant experience from the 2010 or 2014 Board Director selected by At-Large process. English will be the working language of this group. The group must be regionally balanced, with two representatives from each of the five RALOs. Each RALO will also select an Alternate member in the event one of the original members must be replaced. Please note that no member of the BMSPC may submit an Expression of Interest (EOI) for the position of the Board Director selected by At-Large. The ALAC will select the Chair of the BMSPC. The first meeting of the BMSPC will be scheduled for late August or early September. 2) Board Candidate Evaluation Committee (BCEC) The new ALAC Rules of Procedures state the following on the composition and task of the BCEC: "19.3 The ALAC shall name a Board Candidate Evaluation Committee (BCEC) to compile an initial slate of candidates for election to Seat 15. A new BCEC consisting of two delegates selected by each of the RALOs plus a chair selected by the ALAC will be convened for each Board seat selection process. Each RALO shall also select an Alternate member who can replace a member from the same region who for whatever reason is not able to fully participate and such replacement will be at the sole discretion of the BCEC Chair in accordance with BCEC guidelines" "19.4 The task of the BCEC is to identify applicants who would each make an excellent Board Director. [19.4.1] Applicant selected by the BCEC must meet the criteria specified in the ICANN Bylaws Article VI, Section 3 ( http://www.icann.org/en/about/governance/bylaws#VI-3) These criteria include but are not limited to being: a) accomplished persons of integrity, objectivity, and intelligence, with reputations for sound judgment and open minds, and a demonstrated capacity for thoughtful group decision-making; and b) persons with an understanding of ICANN's mission and the potential impact of ICANN decisions on the global Internet community, and committed to the success of ICANN. Moreover, the Director selected by the At-Large Community must understand the mission of At-Large and the needs of the global community of Internet end users." "19.5 No member of the electorate (Paragraph 19.10) may simultaneously serve as a member of the BCEC." According to 19.5, members of the electorate (i.e., members of the ALAC and RALO Chairs who will be serving in 2017) may not be BCEC members. The group must be regionally balanced, with two representatives from each of the five RALOs. Each RALO will also select an Alternate member in the event one of the original members must be replaced. Additionally, no member of the BCEC may submit an Expression of Interest (EOI) for the position of the Board Director selected by At-Large. Please note that experience on the 2010 or 2014 BCEC and/or on the ICANN Nominating Committee would be highly desired. English will be the working language of this group. The ALAC will select the Chair of the BCEC. The first meeting of the BCEC will be scheduled for late August or early September. Regards, Heidi Ullrich, Silvia Vivanco, Ariel Liang, Gisella Gruber, Nathalie Peregrine, Terri Agnew and Yeşim Nazlar ICANN Policy Staff in support of the At-Large Community E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge> [unknown.png]

1 0

9 August 2016 Approved Resolutions
by Rinalia Abdul Rahim Aug. 13, 2016

Aug. 13, 2016

Dear ALAC and Regional Leaders, The Board met on 9 August 2016. Below is the set of resolutions/decisions. Quite a few important items approved including those related to the IANA Stewardship Transition and the GNSO Policy Recommendations on Proxy and Privacy Services. See https://www.icann.org/resources/board-material/resolutions-2016-08-09-en for 9 August 2016 approved ICANN Board resolutions. Text pasted below. Best regards, Rinalia [image: feedback] Skip to main content <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#ma…> - - Log In <https://www.icann.org/users/sign_in> - Sign Up <https://www.icann.org/users/sign_up> [image: Icann logo] <https://www.icann.org/> <https://www.icann.org/get-started> <https://www.icann.org/resources/pages/beginners-guides-2012-03-06-en> <https://www.icann.org/en/about/participate/newcomers> <https://www.icann.org/en/about/participate/fellowships> <https://www.icann.org/news> <https://www.icann.org/news/announcements> <https://www.icann.org/news/blog> <https://www.icann.org/news/multimedia> <https://www.icann.org/en/news/press> <https://www.icann.org/resources/pages/global-newsletter> <https://www.icann.org/policy> <https://www.icann.org/policy#what_is_policy> <https://www.icann.org/policy#how_is_policy_developed> <https://www.icann.org/policy/implementation> <https://www.icann.org/policy#updates> <https://www.icann.org/policy#participate> <https://www.icann.org/policy#staff> <https://www.icann.org/public-comments> <https://www.icann.org/public-comments#open-public> <https://www.icann.org/public-comments#closed-public> <https://www.icann.org/public-comments#upcoming-public> <https://www.icann.org/public-comments/archive> <https://www.icann.org/resources> <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> <https://www.icann.org/resources/pages/accountability-2012-02-25-en> <https://www.icann.org/en/resources/registrars> <https://www.icann.org/en/resources/registries> <https://www.icann.org/en/resources/compliance> <https://www.icann.org/resources/pages/help-2012-02-03-en> <https://www.icann.org/community> <https://www.icann.org/community#groups> <https://www.icann.org/community/explore> <https://features.icann.org/calendar> <https://www.icann.org/community/demographics> <https://www.icann.org/stewardship-accountability> <https://www.icann.org/stewardship> <https://community.icann.org/display/acctcrosscomm/WS1+-+Enhancing+ICANN+Acc…> <https://www.icann.org/stewardship-implementation> Resources - About ICANN <https://www.icann.org/resources/pages/welcome-2012-02-25-en> - Board <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> - Accountability <https://www.icann.org/resources/accountability> - Governance <https://www.icann.org/resources/pages/governance-2012-02-25-en> - Groups <https://www.icann.org/resources/pages/groups-2012-02-06-en> - Business <https://www.icann.org/resources/pages/business> - Civil Society <https://www.icann.org/resources/pages/civil-society-2016-05-24-en> - Contractual Compliance <https://www.icann.org/resources/pages/compliance-2012-02-25-en> - Registrars <https://www.icann.org/resources/pages/registrars-0d-2012-02-25-en> - Registries <https://www.icann.org/resources/pages/registries-46-2012-02-25-en> - GDD Metrics <https://www.icann.org/resources/pages/metrics-gdd-2015-01-30-en> - Identifier Systems Security, Stability and Resiliency (IS-SSR) <https://www.icann.org/resources/pages/is-ssr-2014-11-24-en> - ccTLDs <https://www.icann.org/resources/pages/cctlds-21-2012-02-25-en> - Internationalized Domain Names <https://www.icann.org/resources/pages/idn-2012-02-25-en> - Universal Acceptance Initiative <https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en> - Policy <https://www.icann.org/resources/pages/policy-01-2012-02-25-en> - Public Comment <https://www.icann.org/public-comments> - Root Zone KSK Rollover <https://www.icann.org/resources/pages/ksk-rollover-2016-05-06-en> - Technical Functions <https://www.icann.org/resources/pages/technical-functions-2015-10-15-en> - Contact <https://www.icann.org/resources/pages/contact-2012-02-06-en> - Help <https://www.icann.org/resources/pages/help-2012-02-03-en> Approved Board Resolutions | Special Meeting of the ICANN Board 09 Aug 2016 1. *Consent Agenda: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#1>* 1. *Approval of Minutes <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#1.a>* 2. *Main Agenda: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2>* 1. *Root Zone Evolution Review Committee (RZERC) Charter <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.a>* - *Rationale for Resolutions 2016.08.09.02 – 2016.08.09.03 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 2. *PTI Articles of Incorporation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.b>* - *Rationale for Resolution 2016.08.09.04 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 3. *Root Zone Maintainer Agreement <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.c>* - *Rationale for Resolutions 2016.08.09.05 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 4. *ICANN Restated Articles of Incorporation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.d>* - *Rationale for Resolutions 2016.08.09.06 – 2016.08.09.07 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 5. *GNSO Policy Recommendations on Privacy & Proxy Services Accreditation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.e>* - *Rationale for Resolutions 2016.08.09.08 – 2016.08.09.10 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 6. *Consideration of BGC Recommendation on Reconsideration Request 16-3 (.GAY) <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.f>* 7. *Consideration of Dot Registry v. ICANN IRP Final Declaration <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g>* - *Rationale for Resolutions 2016.08.09.11 – 2016.08.09.13 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 8. *Consideration of Request for Cancellation of HOTEL Top-Level Domain S.a.r.l's (HTLD's) Application for .HOTEL <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h>* - *Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.…>* 3. *Executive Session - Confidential: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3>* 1. *Ombudsman FY16 At-Risk Compensation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.a>* - *Rationale for Resolution 2016.08.09.16 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.…>* 2. *Officer Compensation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.b>* - *Rationale for Resolution 2016.08.09.16 – 2016.08.09.20 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.…>* 1. Consent Agenda: 1. Approval of Minutes Resolved (2016.08.09.01), the Board approves the minutes of the 25 June and 27 June 2016 Meetings of the ICANN Board. 2. Main Agenda: 1. Root Zone Evolution Review Committee (RZERC) Charter Whereas, ICANN developed the proposed Root Zone Evolution Review Committee (RZERC) charter in cooperation with the Implementation Oversight Task Force (IOTF) and the Cross Community Working Group on Naming Related Functions (CWG-Stewardship). Whereas, the proposed charter is consistent with the IANAStewardship Transition Coordination Group (ICG) proposal that the Board approved and transmitted to the National Telecommunications and Information Administration (NTIA) on 10 March 2016. Whereas, ICANN commenced a public comment period from 30 June 2016 to 10 July 2016 < https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en> on the proposed charter < https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.…> [PDF, 43 KB]. Whereas, the public comment forum on the proposed charter closed on 10 July 2016, with ICANN receiving seven comment submissions by both individuals and organizations/groups. Upon review of these comments, ICANN coordinated with the impacted parts of the ICANNcommunity to address the concerns and revise the charter appropriately. Whereas, the RZERC charter calls for a representative from the ICANN Board to serve in the Committee. Resolved (2016.08.09.02), the Board approves the RZERC charter as revised in response to public comment, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to form the RZERC. Resolved (2016.08.09.03), the Board appoints Suzanne Woolf to serve on the RZERC. *Rationale for Resolutions 2016.08.09.02 – 2016.08.09.03* *Why the Board is addressing the issue now?* On 10 March 2016, the Board approved and transmitted the IANA Stewardship Transition Coordination Group (ICG) proposal to the National Telecommunications and Information Administration (NTIA) and directed ICANN to proceed with implementation planning. One of the requirements in the naming portion of the ICG proposal is the formation of a standing committee to review proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. The Committee shall, as determined necessary by its membership, make recommendations related to those changes for consideration by the ICANN Board. The Board's approval at the recommendation of the Committee is the CWG-Stewardship's proposed replacement for NTIA's current role, which would no longer be in place if the IANA Functions Contract lapses. As part of implementation planning, ICANNnamed this standing committee Root Zone Evolution Review Committee (RZERC) and worked with the community to draft a charter for the Committee. *What is the proposal being considered?* The proposed charter describes the purpose, scope of responsibilities, and composition of the Committee. The charter also sets out how the Committee will conduct itself, including frequency and method of meetings, how decisions will be made, records of proceedings, as well as conflict of interest. Lastly, the charter sets out requirements for review and amendments to the charter. *Which stakeholders or others were consulted?* ICANN consulted with the Implementation Oversight Task Force (IOTF) as well as the CWG-Stewardship in the development of the proposed charter. ICANN also conducted a public comment period on the proposed charter from 10 June 2016 through 10 July 2016, following which time the comments were summarized and analyzed. *What concerns or issues were raised by the community?* Seven (7) members of the community participated in the public comment period. Members of the community raised one key concern in their comments. The concern was that the scope of responsibilities of the RZERC as drafted seems to overlap with the responsibilities of the RSSAC. The scope of the RZERC as drafted is to consider architectural and operational issues that impose potential risk to the root zone and the root system. Commenters suggested that this scope could be interpreted to mean that the RZERC could consider issues relating to the operation of the root servers, which is a responsibility of the RSSAC. To address this concern, ICANNworked with the RSSAC to modify the scope of the RZERC to clarify that the RZERC is expected to review proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. The Committee shall, as determined necessary by its membership, make recommendations related to those changes for consideration by the ICANN Board. *What significant materials did the Board review?* As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents: - The proposed RZERC charter < https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.…> [PDF, 43 KB] - Public comments < https://forum.icann.org/lists/comments-draft-rzerc-charter-10jun16/ > - Summary and analysis of public comments - IANA Stewardship Transition Coordination Group (ICG) proposal < https://www.icann.org/en/system/files/files/iana-stewardship-transition-pro…> [PDF, 2.32 MB] - The RZERC charter as modified in response to public comment. *Are there positive or negative community impacts?* The Board's approval of the charter is an important step in the implementation planning process to fulfill one of the requirements from the ICGproposal, which was endorsed by the global stakeholder community and approved by the Board on 10 March 2016. *Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?* There is no fiscal impact expected. *Are there any security, stability or resiliency issues relating to the DNS?* The approval of the proposed charter would be an important step toward ensuring security, stability and resiliency of the DNS post transition. The RZERC's scope of responsibility will be to provide the ICANNBoard with recommendations regarding proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. 2. PTI Articles of Incorporation Whereas, on 14 March 2014, the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce announced its intention to transition the stewardship of the IANA Functions to the global multistakeholder community. Whereas, on 10 March 2016, Internet Corporation for Assigned Names and Numbers (ICANN) accepted and transmitted to the NTIA the following transition documents: (i) the IANA Stewardship Transition Coordination Group's IANA Stewardship Transition Proposal, (the "ICG Proposal") and (ii) the Cross Community Working Group on Enhancing ICANN Accountability's Work Stream 1 Report (collectively, the "Transition Proposals"). Whereas, the ICG Proposal included a requirement that ICANN develop an affiliate to perform the naming-related IANA functions under a contract with ICANN, PTI. The ICGProposal required PTI to be a California Nonprofit Public Benefit Organization, and ICANN is to be the sole member of PTI. Whereas, ICANN lawyers worked diligently with the independent counsel to the Cross Community Working Group to Develop an IANAStewardship Transition Proposal on Naming Related Functions ("CWG-Stewardship") to develop Articles of Incorporation for the new PTI. Those draft Articles were posted for public comment for a period of 30 days. Whereas, upon the close of the comment period, a detailed analysis of the comments was performed and modifications were made to the Articles in response to the public comments. ICANN coordinated with the independent law firm on the revisions. Whereas, ICANN's General Counsel has asserted that the proposed PTI Articles of Incorporation remain consistent with the Transition Proposals and recommends that ICANNproceed to forming the affiliate to allow for implementation planning to continue. Resolved (2016.08.09.04), the ICANN Board authorizes ICANN's CEO, or his designee, to proceed with the formation of PTI, including the filing of the proposed PTI Articles of Incorporation as revised after public comment. *Rationale for Resolution 2016.08.09.04* The authorization for ICANN to proceed with the formation of PTI, through the filing of the PTI Articles of Incorporation, is a crucial step in the planning for the implementation of the Transition Proposals. This is a key step for ICANN's report to NTIA on the status of implementation planning. This timely authorization to move forward with the formation of PTI is necessary to support the global multistakeholder community's work towards a successful completion of the stewardship of the IANA functions. These PTI Articles are product of collective work of the internal and external legal teams along with the intensive work of the CWG-Stewardship. The PTI Articles were posted for a 30-day public comment period, and three comments were received. Each of the comments was considered and analyzed, and explanation was provided on whether the PTI Articles required modification to reflect the issues raised within the comment. With the small number of comments, the Articles did not require significant change in response to those comments. The changes that were made included a modification to the purpose of PTI to more accurately reflect PTI's limited, narrow role to perform the IANAfunctions. Another change was made to reflect the proper threshold needed to amend the PTI Articles. In taking this action, the Board relied upon: - ICG's IANA Stewardship Transition Proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-pro…> [PDF, 2.32 MB] - Report of Public Comments on PTI Articles of Incorporation - Draft PTI Articles of Incorporation The Board also relied upon the General Counsel and Secretary's affirmation that PTI Articles reflect the Transition Proposals, as well as the inputs of independent counsel to craft the PTI Articles to support the ICG Proposal. Authorizing the formation of PTI is in line with ICANN's commitment to accountability and transparency. This action confirms ICANN's commitment to implement the Transition Proposals and all of the elements in those Proposals. Forming PTI is not anticipated to have any impact on the security, stability or resiliency of the DNS, though the PTI will be essential to ICANN's security, stability and resiliency work. There will be resource implications, including significant resources to support a new affiliate. This is an Organizational Administrative Function for which public comments were received. 3. Root Zone Maintainer Agreement Whereas, the National Telecommunications and Information Agency (NTIA) officially requested that Verisign and ICANN work together to develop a proposal on how best to transition NTIA's administrative role associated with root zone management in a manner that maintains the security, stability, and resiliency of the Internet's domain name system in a 4 March 2015 letter to ICANN. Whereas, in August 2015, ICANN and Verisign submitted a proposal to NTIA in response to its request < https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pr…> [PDF, 247 KB]. The proposal outlines two parts, a parallel testing period of the of Root Zone Management Systems (RZMS) and a Root Zone Maintainer Agreement (RZMA) with Verisign for Verisign to continue performing the root zone maintainer function it performs today under the Cooperative Agreement <https://www.ntia.doc.gov/page/verisign-cooperative-agreement> with the Department of Commerce. Whereas, NTIA specified in a 9 June 2016 letter to ICANN that a finalized RZMA and successful completion of the parallel testing period are pre-conditions to the IANA Stewardship transition. Whereas, the completion of the RZMA is a requirement from the package of proposals that the Board approved on 10 March 2016 to transition NTIA's stewardship of the IANA function to the global multistakeholder community and, because the RZMA exceeds US$500,000 in total, requires that the Board approves to delegate signature authority to the CEO. Whereas, the parallel testing period of the RZMS successfully concluded on 6 July 2016 < https://www.icann.org/news/announcement-2016-07-14-en>. Whereas, ICANN and Verisign finalized negotiations on the terms of the proposed RZMA for Verisign to perform the root zone maintainer function, and published the proposed RZMA for a 30-day notice period as required by the IANAStewardship Transition Coordination Group (ICG) proposal < https://www.icann.org/news/blog/root-zone-management-transition-update-pres… >. Whereas, the proposed RZMA contains provisions that incorporate relevant requirements from the Cross Community Working Group on Naming Related Functions (CWG-Stewardship). Whereas, the Board Finance Committee reviewed the financial aspects and implications of the RZMA and found (i) that the proposed costs of the contract were reasonable, (ii) that the procurement process had been respected, (iii) that the costs were affordable, and recommended approval by the Board as a result. Resolved (2016.08.09.05), the proposed RZMA is approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement. *Rationale for Resolutions 2016.08.09.05* *Why the Board is addressing the issue now?* In a 4 March 2015 letter, the National Telecommunications and Information Agency (NTIA) "officially requested that Verisign and ICANN work together to develop a proposal on how best to transition NTIA's administrative role associated with root zone management in a manner that maintains the security, stability, and resiliency of the Internet's domain name system." In August 2015, ICANNand Verisign submitted a proposal to NTIA in response to its request < https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pr…> [PDF, 247 KB]. The proposal outlines two parts, a parallel testing period of the of Root Zone Management System (RZMS) and a Root ZoneMaintainer Agreement with Verisign for Verisign to continue performing the root zone maintainer function it performs today under the Cooperative Agreement <https://www.ntia.doc.gov/page/verisign-cooperative-agreement> with the Department of Commerce. Completion of the RZMA is also specified as one of the requirements from the package of proposals that the Board approved on 10 March 2016 to transition NTIA's stewardship of the IANA function to the global multistakeholder community and, because it exceeds US$500,000 in total, requires that the Board approves to delegate signature authority to the CEO. Since last August, ICANN and Verisign have had ongoing discussions and negotiations regarding the terms of the RZMA. Negotiations concluded in June and the proposed RZMA was published for a 30-day public notice period on 30 June 2016. The 30-day public notice period ended on 30 July 2016 and the Board has considered the proposed RZMA for approval. *What is the proposal being considered?* The proposed RZMA allows Verisign to continue providing services for root zone maintenance, root zone signing with the ZSK, and distribution of the root zone file and related files to the root zone operators at a nominal fee. The RZMA provides for an 8-year term with robust service level agreements that can be modified via a change control process should the customers of IANA require changes to these service level agreements. The change control process also allows for changes to the Root Zone Management System as root zone management evolves to meet the needs of the community. While the 8-year term of the RZMA is intended to promote the security, stability and resiliency of root zone maintenance operations by having Verisign continue in its role, the agreement also provides a capability for the community, through a consensus-based community-driven process, to cause ICANNto transition the function to another service provider after three years. The full RZMA was posted for a 30-day public notice period on 30 June 2016 as required by the ICG proposal and can be viewed at < https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0 >. *Which stakeholders or others were consulted?* ICANN held discussions and negotiations with Verisign, Inc. to finalize the proposed RZMA, which was then posted for a 30-day public notice period from 30 June through 30 July 2016. *What concerns or issues were raised by the community?* No significant issues or concerns were brought to ICANN's attention during the 30-day public notice period. *What significant materials did the Board review?* As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents: - Verisign Cooperative Agreement with the United States Government < https://www.ntia.doc.gov/page/verisign-cooperative-agreement> - 4 March 2015 letter from NTIA - Verisign/ICANN Proposal in Response to NTIARequest – Root ZoneAdministrator Proposal Related to the IANAFunctions Stewardship Transition < https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pr…> [PDF, 247 KB] - Root Zone Maintainer Agreement < https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0 > - IANA Stewardship Transition Coordination Group (ICG) proposal < https://www.icann.org/en/system/files/files/iana-stewardship-transition-pro…> [PDF, 2.32 MB] *What factors has the Board found to be significant?* The Board carefully considered the RZMA to ensure it contains provisions that would allow ICANN to meet the requirements of the community for the transition, such as: - The ability to modify service level agreements due to recommendations from the Customer Standing Committee - The ability to make modifications to the Root Zone Management System due to recommendations from the Root ZoneEvolution Review Committee - The ability for the community, through a consensus-based community-driven process, to cause ICANN to transition the maintainer function to another service provider - The Board also carefully considered the terms of the RZMA to ensure that the maintainer function can continued to be operated in a secure, stable, and reliable manner post transition. *Are there positive or negative community impacts?* A key goal of the proposed RZMA and continued engagement with Verisign, Inc. for the performance of the maintainer function is to provide secure and stable operations of the root zone through the IANAStewardship transition and beyond. The Board's approval of the proposed RZMA would ensure that expectations of IANA customers will continue to be met. *Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?* Verisign, Inc. has historically solely performed the maintainer function at no cost and contracting directly with Verisign, Inc. for the continued performance of this work is desirable to ensure continuity, security and stability during the transition period. The terms of the RZMA allow for the community, through a consensus-based community-driven process, to cause ICANNto transition the maintainer function to another service provider. This contract creates a nominal annual fee of USD 300,000 per year due to Verisign, Inc. for the performance of the maintainer function. The ICANN Board Finance Committee has reviewed the financial aspects and implications of the proposed RZMA and recommended approval of the RZMA to the ICANN Board, on the basis of this review. *Are there any security, stability or resiliency issues relating to the DNS?* The Board's approval of the proposed RZMA would ensure continuity, security and stability of the operation of the root zone during the transition period and beyond. 4. ICANN Restated Articles of Incorporation Whereas, on 14 March 2014, the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce announced its intention to transition the stewardship of the IANA Functions to the global multistakeholder community. Whereas, on 10 March 2016, Internet Corporation for Assigned Names and Numbers (ICANN) accepted and transmitted to the US National Telecommunications and Information Agency the following transition documents: (i) the IANA Stewardship Transition Coordination Group's IANAStewardship Transition Proposal, (the "ICG Proposal") and (ii) the Cross Community Working Group on Enhancing ICANNAccountability's Work Stream 1 Report (collectively, the "Transition Proposals"). Whereas, the ICANN Articles of Incorporation need to be restated in order to align with the new ICANN Bylaws and for consistency with the Transition Proposals. Whereas, ICANN lawyers worked diligently with the independent counsel to the CCWG-Accountability to develop Restated Articles of Incorporation for ICANN. Those Restated Articles were posted for public comment for over 40 days. Whereas, upon the close of the comments, a detailed analysis of the comments was performed and modifications were made to the Articles in response to the public comments. ICANNcoordinated with the independent law firms on the revisions. Whereas, ICANN's General Counsel has asserted that the proposed Restated ICANNArticles of Incorporation remain consistent with the Transition Proposals and recommends that the Board approve the amendment to ICANN's Articles and authorize ICANN to proceed to filing at the appropriate time. Resolved (2016.08.09.06), the ICANN Board approves the proposed amendments to ICANN's Articles of Incorporation, which shall be deemed effective upon the expiration the IANA Functions Contract between ICANN and NTIA. Resolved (2016.08.09.07), the ICANN Board authorizes ICANN's CEO, or his designee, to proceed with the filing of the Restated Articles of Incorporation once they are effective. *Rationale for Resolutions 2016.08.09.06 – 2016.08.09.07* The adoption of the Restated Articles of Incorporation is another key step in the planning for the implementation of the Transition Proposals. The Board is being taking this action now to support ICANN's transition planning status report to NTIAdue on 12 August 2016. The adoption of amendments to ICANN Articles of Incorporation completes the changes to ICANN's key governance documents that is necessary to align with the Transition Proposals and support the global multistakeholder community's work towards a successful completion of the stewardship of the IANAfunctions. These Restated Articles were developed jointly between the legal teams in coordination with the ICANN community. The external counsel to the CCWG-Accountability, as well as ICANN's lawyers, worked closely with the CCWG-Accountability to confirm its understanding and support of the document. The proposed Restated Articles were posted for public for over 40 days, including a requested extension. Six comments were received. Each of the comments was considered and analyzed, and explanation was provided on whether the Articles required modification to reflect the issues raised within the comment. The legal teams continued their close coordination in developing the necessary updates to the Articles. The changes to the draft Articles based on comments were limited. In taking this action, the Board relied upon: - ICG's IANA Stewardship Transition Proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-pro…> [PDF, 2.32 MB] - Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) Work Stream 1 Report ("Report") to the ICANN Board <https://www.icann.org/en/system/files/files/ccwg-accountability-supp-propos…> [PDF, 6.03 MB] - Report of Public Comments Proposed Restated Articles of Incorporation (clean and redline to existing Articles) The Board also relied upon the General Counsel and Secretary's affirmation that the Restated Articles reflect the Transition Proposals, as well as the work of the independent counsel to craft the Articles in support of the Transition Proposals. The adoption of these Articles is in line with ICANN's commitment to accountability and transparency, as this completes the key governance document that ICANN needs to put in place to provide the community with the new and enhanced accountability tools. This action confirms ICANN's commitment to adopt the accountability changes. The adoption of these Restated Articles is not anticipated to have any impact on the security, stability or resiliency of the DNS. The resource implications for these Restated Articles are the same as the potential resource implications identified for the implementation of the new ICANN Bylaws. This is an Organizational Administrative Function for which public comments were received. 5. GNSO Policy Recommendations on Privacy & Proxy Services Accreditation Whereas, on 31 October 2013, the GNSO Council approved the charter for a Working Group to conduct a Policy Development Process that had been requested by the ICANN Board concerning the accreditation by ICANN of privacy and proxy domain name registration service providers, as further described at http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf [PDF, 463 KB]. Whereas, the PDP followed the prescribed PDP steps as stated in the ICANN Bylaws, resulting in a Final Report being delivered to the GNSO Council on 8 December 2015. Whereas, the Privacy & Proxy Services Accreditation Issues PDP Working Group (WG) reached Full Consensus on all its final recommendations (see http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf [PDF, 1.24 MB]). Whereas, the GNSO Council reviewed and discussed the final recommendations of the Privacy & Proxy Services Accreditation Issues PDP WG, and adopted the recommendations on 21 January 2016 by a unanimous vote (see http://gnso.icann.org/en/council/resolutions - 201601 <http://gnso.icann.org/en/council/resolutions#201601>.) Whereas, the GNSO Council vote exceeded the required voting threshold (i.e. supermajority) to impose new obligations on ICANNcontracted parties. Whereas, in accordance with the ICANN Bylaws, a public comment period was opened on the approved recommendations to provide the community with a reasonable opportunity to comment on their adoption prior to action by the ICANN Board, and the comments received have been summarized and reported (see https://www.icann.org/en/system/files/files/report-comments-ppsai-recommend… [PDF, 299 KB]). Whereas, the ICANN Bylaws provide that the Board is to request the GAC's opinion regarding "any policies that are being considered by the Board for adoption that substantially affect the operation of the Internet or third parties, including the imposition of any fees or charges" and "take duly into account any advice timely presented" as a result. Whereas, the Board notified the GAC of the publication of the GNSO's final recommendations for public comment on 19 February 2016 (see https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Cro… GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2 <https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Cro…>[PDF, 819 KB]). Whereas, in its Marrakech Communiqué issued on 9 March 2016 the GAC advised the ICANN Board that it needed more time to consider potential public policy concerns relating to the adoption of the final PDPrecommendations (see https://gacweb.icann.org/download/attachments/28278854/GACMorocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 <https://gacweb.icann.org/download/attachments/28278854/GAC%20Morocco%2055%2…>[PDF, 567 KB]). Whereas, on 15 May 2016 the Board acknowledged receipt of the GNSO's PDPrecommendations and resolved to consider them at its first meeting following ICANN56 to enable the GAC to provide timely advice, if any (see https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a <https://www.icann.org/resources/board-material/resolutions-2016-05-15-en#2.a> ). Whereas, in its Helsinki Communiqué issued on 30 June 2016 the GAC advised the ICANN Board to direct that the GAC's concerns be effectively addressed to the greatest extent feasible by the Implementation Review Team that is to be convened to implement the adopted recommendations (see https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?pre…, 328 KB]). Resolved (2016.08.09.08), the Board hereby adopts all the final recommendations of the Privacy & Proxy Services Accreditation Issues PDP Working Group, as passed by a unanimous vote of the GNSO Council on 21 January 2016 ("Privacy/Proxy Policy Recommendations"). Resolved (2016.08.09.09), the Board directs the President and CEO, or his authorized designee, to develop and execute an implementation plan, including costs and timelines, for the Privacy/Proxy Policy Recommendations consistent with ICANN Bylaws Annex A and the Implementation Review Team Guidelines & Principles endorsed by the Board on 28 September 2015 (see https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f <https://www.icann.org/resources/board-material/resolutions-2015-09-28-en#2.f>), and to continue communication with the community on such work. In the event that policy issues arise in the course of implementation discussions, they should be referred back to the GNSO in accordance with the framework for implementation associated with GNSO policy recommendations, including the Implementation Review Team Guidelines & Principles. Resolved (2016.08.09.10), the Board acknowledges the GAC's advice from the Helsinki Communiqué regarding the Privacy/Proxy Policy Recommendations. The Board will consider the GAC's advice and provide input to the Implementation Review Team for consideration in implementation planning. *Rationale for Resolutions 2016.08.09.08 – 2016.08.09.10* *Why is the Board addressing the issue now?* In initiating negotiations with the Registrar Stakeholder Group for new form of Registrar Accreditation Agreement (RAA) in October 2011, the ICANNBoard also requested an Issue Report from the GNSO that, upon the conclusion of the RAAnegotiations, would start a GNSO PDP to address remaining issues not dealt with in the RAA negotiations. In June 2013, the ICANN Board approved a new 2013 RAA, and the topic of accrediting privacy and proxy services was identified as the sole issue to be resolved through a GNSO PDP. This topic had also been noted by the Whois Review Team in its Final Report, published in May 2012, in which the Review Team had highlighted the current lack of clear and consistent rules regarding these services, resulting in unpredictable outcomes for stakeholders. The Review Team thought that appropriate regulation and oversight over such services would address stakeholder needs and concerns, and recommended that ICANNconsider an accreditation system. Until the development of an accreditation program, only certain aspects of such services are covered by an interim specification to the 2013 RAA, which is due to expire on 1 January 2017 or the implementation by ICANN of an accreditation program, whichever first occurs. The GNSO Council approved all the final recommendations from the PDP Working Group's Final Report dated 8 December 2015 at its meeting on 21 January 2016, as well as a Recommendations Report to the Board in February 2016. In accordance with the ICANNBylaws, a public comment period was opened to facilitate public input on the adoption of the recommendations following which the PDPrecommendations were forwarded to the Board for its review. On 15 May 2016, the Board resolved to consider action on the recommendations at the first Board meeting following ICANN56 in Helsinki, Finland, to enable the GAC to provide timely advice on public policy concerns raised by the PDP recommendations, if any. The GAC's advice in its Helsinki Communiqué was for the Board to direct that the GAC's concerns be effectively addressed to the greatest extent possible during the implementation phase of the PDP recommendations. *What is the proposal being considered?* The GNSO's policy recommendations include minimum mandatory requirements for the operation of privacy and proxy services; the maintenance of designated contact points for abuse reporting and the publication of a list of accredited providers; requirements related to the handling of requests for disclosure and/or publication of a customer's contact details by certain third party requesters; conditions regarding the disclosure and publication of such details as well as the refusal to disclose or publish; and principles governing the de-accreditation of service providers. The full list and scope of the final recommendations can be found in Annex A of the GNSO Council's Recommendations Report to the Board (see http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16… [PDF, 491 KB]. *Which stakeholders or others were consulted?* As required by the GNSO's PDPManual, the Working Group reached out to all GNSOStakeholder Groups and Constituencies as well as other ICANN Supporting Organizations and Advisory Committees for input during the early phase of the PDP. The Working Group also held open community sessions at all the ICANN Public Meetings that occurred during the life cycle of this PDP. It also sought input on potential implementation issues from ICANN's Registrar Services and Compliance teams. Public comment periods were opened for the Preliminary Issue Report that preceded the PDP, the Working Group's Initial Report, and the GNSO Council's adoption of the Working Group's Final Report. The final recommendations as detailed in the Final Report were completed based on the Working Group's review and analysis of all the public comments and input received in response to its Initial Report. Following the GAC's advice in its Marrakech Communiqué of 9 March 2016 and the Board's resolution of 15 May 2016, discussions also took place amongst the Board and community on the topic at ICANN56 in Helsinki, Finland. *What concerns or issues were raised by the community?* A significant number of public comments were received by the Working Group concerning the possibility that a distinction might be made between domain name registrants with domains serving non-commercial purposes and registrants who conduct online financial transactions. This had been an open question in the Working Group's Initial Report, as at the time a number of Working Group members had supported that distinction. As a result of further Working Group deliberations following review of the public comments received, the Working Group reached consensus on a recommendation that no such distinction be made for purposes of accrediting services. Concerns had also been expressed over the need to ensure that there are adequate safeguards in place for maintaining the privacy of customer data, and that a reasonable balance is struck as between a legitimate need for access to information (e.g. by law enforcement and intellectual property rights-holders) and that of protecting privacy. Many public comments received in response to the Working Group's Initial Report also highlighted the potential dangers of disclosing private information without cause, including the threat to the physical safety of certain groups of domain name registrants and privacy/proxy customers. The Working Group's final recommendations include a number of suggested principles and policies that aim to provide more concrete guidance than exists at present for privacy and proxy services, third party requesters of customer information, and domain name registrants in relation to topics such as the handling of customer notifications, information requests and domain name transfers. The Working Group also received several comments concerning the lack of a detailed framework for the submission and confidential handling of disclosure requests from law enforcement authorities, including from the GAC's Public Safety Working Group. In its Initial Report, the Working Group sought community input on the question as to whether and how such a framework might be developed as well as on more specific questions such as whether it should be mandatory for accredited providers to comply with express requests from law enforcement authorities in the provider's jurisdiction not to notify a customer. Based on input received, the Working Group agreed that accredited privacy and proxy service providers should comply with express law enforcement requests not to notify a customer where this is required by applicable law. Providers would be free to voluntarily adopt more stringent standards or otherwise cooperate with law enforcement authorities. The Working Group's Final Report also contains a suggestion for certain minimum requirements that could be included if such a framework is to be developed during the implementation phase of the adopted PDP recommendations. *What significant materials did the Board review?* The Board reviewed the PDPWorking Group's Final Report, the GNSO Council's Recommendations Report on the topic to the Board, the summary of public comments received in response to the public comment period that was opened following the GNSOCouncil's adoption of the recommendations contained in the Final Report, and GACadvice received on the topic, as provided in the Marrakech and Helsinki Communiqués. *What factors did the Board find to be significant?* The recommendations were developed following the GNSOPolicy Development Process as set out in Annex A of the ICANNBylaws and have received the unanimous support of the GNSOCouncil. As outlined in the ICANN Bylaws, the Council's supermajority support obligates the Board to adopt the recommendations unless, by a vote of more than two-thirds, the Board determines that the recommended policy is not in the best interests of the ICANNcommunity or ICANN. The Bylaws also allow for input from the GAC in relation to public policy concerns that might be raised if a proposed policy is adopted by the Board. The GAC had raised this possibility with respect to this PDP and the Board will continue to consider the advice that the GAC provided. *Are there positive or negative community impacts?* Developing a full accreditation program for privacy and proxy service providers will require significant resources and take a substantial period of time. It is likely that the interim specification contained in the 2013 RAA will need to be extended beyond its current expiration date of 1 January 2017, to allow for development of such a program. Implementing the GNSO's recommendations will result in a more uniform set of standards for many aspects of privacy and proxy services, including more consistent procedures for the handling, processing and determination of third party requests by accredited providers, into which reasonable safeguards to protect consumer privacy can be incorporated and public policy concerns highlighted by the GACaddressed as far as possible. At present, there is no accreditation scheme in place for privacy and proxy services and no agreed community-developed set of best practices for the provision of such services. This PDPrepresents an attempt to develop a sound basis for the development and implementation of an accreditation framework by ICANN and is part of ICANN's on-going efforts to improve the Whois system, including implementing recommendations made previously by the Whois Review Team. Nevertheless, as highlighted above, the implementation of all the recommendations from the PDP will be time and resource-intensive due to the scale of the project and the fact that this will be the first time ICANN has implemented such a program for this industry sector. While the RAA may serve as a useful reference point for this program, the Working Group's Final Report acknowledged that this may not be the most appropriate model for a number of reasons. Ensuring that the implementation planning addresses as fully as possible the public policy concerns that have been identified by the GAC, including possibly developing a disclosure framework for law enforcement authorities, is likely to form a substantial part of the implementation work. The Working Group's Final Report also notes areas where additional work may be required, which could increase the community's workload in the near term. For example, the issue of privacy and proxy services in the context of domain name transfers will need to be addressed in the next review of the Inter-Registrar Transfer Policy. *Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?* There may be fiscal impacts on ICANN associated with the creation of a new accreditation program specifically covering providers of privacy and proxy services. The implementation plan should take into account costs and timelines for implementation. As the current interim specification in the RAAapplicable to such services is due to expire on 1 January 2017, consideration will also need to be given to extending its duration upon adoption of the PDP recommendations. *Are there any security, stability or resiliency issues relating to the DNS?* There are no security, stability or resiliency issues relating to the DNS that can be directly attributable to the implementation of the PDPrecommendations. While the accreditation of privacy and proxy service providers is part of the overall effort at ICANN to improve the Whois system, it does not affect or change either the Whois protocol (including the rollout of the new RDAP) or the current features of the Whois system. The Working Group made its final recommendations with the understanding that implementation of its recommendations would be done in the context of any other policy or technical changes to the Whois system, which are outside the scope of this PDP. 6. Consideration of BGC Recommendation on Reconsideration Request 16-3 (.GAY) Item removed from agenda. 7. Consideration of Dot Registry v. ICANN IRP Final Declaration Whereas, on 29 July 2016, an Independent Review Process (IRP) Panel (Panel) issued its Final Declaration in the IRP filed by Dot Registry, LLC (Dot Registry) against ICANN (Final Declaration). Whereas, the Panel majority declared that "the actions and inactions of the Board were inconsistent with ICANN's Articles of Incorporation and Bylaws" in that "the Board (acting through the BGC) failed to exercise due diligence and care in having a reasonable amount of facts in front of them and failed to fulfill its transparency obligations," and that the evidence before the Panel did not support a determination that the Board (acting through the BGC) exercised independent judgment in reaching the reconsideration decisions. (See Final Declaration, ¶¶ 151-152.) Whereas, the Panel majority further declared that "Dot Registry is the prevailing party" and that ICANN shall pay to Dot Registry US$235,294.37 "upon demonstration that these incurred costs have been paid in full." (Id. ¶ 154.) Whereas, "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (*Id.* at ¶ 153.) Whereas, the Panel majority did not make any recommendations to the Board as to what, if any, subsequent action the Board should take in furtherance of the Final Declaration. Whereas, Dot Registry has stated in a letter to the Board, among other things, that its "90 page expert report" is "sufficient and compelling to assist the Board with determining that Dot Registry's applications should have passed CPE" and requesting that ICANN "proceed to contracting with Dot Registry for .INC, .LLC, and .LLP. (See https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-…, 1.5 MB]). Whereas, the Panel considered and challenged the current standard of review employed by the BGC in reviewing Reconsideration Requests. Whereas, in accordance with Article IV, section 3.21 of ICANN's Bylaws, the Board has considered the Final Declaration. Resolved (2016.08.09.11), the Board accepts the findings of the Final Declaration that: (i) Dot Registry is the prevailing party in the Dot Registry, LLC v. ICANNIRP; and (ii) ICANN shall pay to Dot Registry US$235,294.37 upon demonstration that these incurred costs have been paid in full. Resolved (2016.08.09.12), the Board has noted the other findings in the Declaration and the findings regarding the Panel majority's statements with respect to the standard of review for Reconsideration Requests referenced above, and will consider next steps in relation to Dot Registry's Reconsideration Requests or the relevant new gTLDs before the Board takes any further action. Resolved (2016.08.09.13), in light of the recent letter received from Dot Registry and the factual inaccuracies that have been reported in online blogged reports, the Board directs the Secretary, or his designee(s), to post the Board briefing materials on this matter simultaneously with the resolutions. *Rationale for Resolutions 2016.08.09.11 – 2016.08.09.13* Dot Registry, LLC (Dot Registry) initiated Independent Review Process (IRP) proceedings challenging the Board Governance Committee's (BGC's) denial of Dot Registry's Reconsideration Requests regarding the Community Priority Evaluation (CPE) reports finding that Dot Registry's applications for .INC, .LLC, and .LLP, respectively, did not prevail in CPE. Dot Registry applied for the opportunity to operate the new top-level domains .LLC, .INC, and .LLP. Dot Registry is one of nine applicants for .LLC, one of eleven applicants for .INC, and one of four applicants for .LLP. Dot Registry, however, is the only applicant that submitted community-based applications for these gTLDs. The CPE panels evaluating Dot Registry's applications (CPE Panels) determined that the applications did not meet the criteria required to prevail in CPE, awarding only five of the 14 points needed to prevail in CPE (CPE Reports). Dot Registry filed Reconsideration Requests 14-30, 14-32, and 14-33, seeking reconsideration of the CPE Reports. On 24 July 2014, the Board Governance Committee (BGC) denied the Reconsideration Requests, finding that Dot Registry had "failed to demonstrate that the Panels acted in contravention of established policy or procedure in rendering their respective CPE Reports…." Dot Registry initiated this IRP on 22 September 2014, challenging the BGC's denial of Dot Registry's Reconsideration Requests, as well as purportedly challenging ICANN's appointment of the Economist Intelligence Unit (EIU) as the third party provider to conduct CPEs, and the Board's response to advice from ICANN's Governmental Advisory Committee regarding .LLC, .INC, and .LLP. In a 2-1 decision, the Panel majority declared Dot Registry to be the prevailing party, and determined that "the actions and inactions of the Board were inconsistent with ICANN's Articles of Incorporation and Bylaws." (Final Declaration at ¶ 151.) Specifically, the Panel majority declared that "the Board (acting through the BGC) failed to exercise due diligence and care in having a reasonable amount of facts in front of them and failed to fulfill its transparency obligations" and that there was not sufficient evidence to "support a determination that the Board (acting through the BGC) exercised independent judgment in reaching the reconsideration decisions." (Id. at ¶¶ 151-152.) The Panel majority further declared that ICANN "shall pay to Dot Registry, LLC $235,294.37 representing said fees, expenses and compensation previously incurred by Dot Registry, LLC upon determination that these incurred costs have been paid in full." (Id. at ¶ 154.) The Board has noted that the Panel majority stated that "in reaching these conclusions, the Panel is not assessing whether ICANN staff or the EIU failed themselves to comply with obligations under the Articles, the Bylaws, or the [Applicant Guidebook (Guidebook)]." (Id. at ¶ 152.) Further, it is also noted that "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (Id. at ¶ 153.) The Panel majority did consider and challenge the current standard of review employed by the BGC in reviewing Reconsideration Requests, stating that it thought the standard to be applied by the BGC in "evaluating a Reconsideration Request" should be: "Is the action taken consistent with the Articles, the Bylaws, and the [Guidebook]?" (Id. at ¶ 79.) The Panel majority further indicated that, in reviewing Reconsideration Requests, "the BGC must determine whether the CPE (in this case the EIU) and ICANNstaff respected the principles of fairness, transparency, avoiding conflicts of interest, and non-discrimination as set out in the ICANN Articles, Bylaws and [Guidebook]" (id. at ¶ 88), and that third parties such as the EUI are "obligated to comply with ICANN's Articles and Bylaws." (Id. at ¶ 101.) The Board acknowledges the important statements by the Panel with respect to the standard of review for Reconsideration Requests and will consider next steps in relation to Dot Registry's Reconsideration Requests or the relevant new gTLDs before the Board takes any further action. As required, the Board has considered the Final Declaration. As this Board has previously indicated, the Board takes very seriously the results of one of ICANN's long-standing accountability mechanisms. Accordingly, and for the reasons set forth in this Resolution and Rationale, the Board has accepted the Panel's Final Declaration as indicated above. The Board also notes that it has received a letter from Dot Registry, dated 6 August 2016, stating, among other things, that its "90 page expert report" is "sufficient and compelling to assist the Board with determining that Dot Registry's applications should have passed CPE" and requesting that ICANN "proceed to contracting with Dot Registry for .INC, .LLC, and .LLP." (See Attachment B to Reference Materials and https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-…, 1.5 MB].) The Board would like to reiterate that "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (*Id.* at ¶ 153.) Further, the Board notes that there are numerous other applications pending for these gTLDs (nine for .INC, eight for .LLC, and three for .LLP), which also must be considered. Accordingly, as noted above, the Board will consider next steps before taking any further action with respect to Dot Registry's Reconsideration Requests, or the .INC, .LLC, or .LLP applications. Finally, the Board also notes that there have been online blogged reports about what the Final Declaration actually says, yet many of the items reported on have been factual inaccuracies, which have been identified and corrected in Attachment C to the Reference Materials related to this agenda item. This action is not expected to have any direct financial impact on the organization, although there could be some indirect costs, such as analysis relating to the standard on Reconsideration Requests. This action will not have any direct impact on the security, stability or resiliency of the domain name system. This is an Organizational Administrative function that does not require public comment. 8. Consideration of Request for Cancellation of HOTEL Top-Level Domain S.a.r.l's (HTLD's) Application for .HOTEL Whereas, Travel Reservations SRL (formerly Despegar Online SRL), Famous Four Media Limited, Fegistry LLC, Minds + Machines Group Limited, Donuts Inc., and Radix FZC (collectively, .HOTEL Claimants) have requested that ICANNcancel HOTEL Top-Level Domain S.a.r.l's (HTLD's) application for .HOTEL. Whereas, the .HOTEL Claimants' request is premised on Dirk Krischenowski's apparent business connections to HTLD, coupled with his exploitation of the portal issue that allowed parties to access confidential information of various applicants for new gTLDs, including information of several of the .HOTEL Claimants. Whereas, ICANN's forensic investigation of the portal issue determined that Mr. Krischenowski's unauthorized access to confidential information did not occur until after HTLD submitted its application in 2012 and after HTLD elected to participate in CPE on 19 February 2014. Whereas, ICANN has not uncovered any evidence that: (i) the information Mr. Krischenowski may have obtained as a result of the portal issue was used to support HTLD's application for .HOTEL; or (ii) any information obtained by Mr. Krischenowski enabled HTLD's application to prevail in CPE. Resolved (2016.08.09.14), the Board concludes that cancellation of HTLD's application for .HOTEL is not warranted. Resolved (2016.08.09.15), the Board directs the President and CEO, or his designee(s), to move forward with processing HTLD's application for .HOTEL. *Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15* HTLD and the .HOTEL Claimants each applied for .HOTEL and were all placed in a contention set. As HTLD's application was community-based, its application was invited to participate in Community Priority Evaluation (CPE) on 19 February 2014. HTLD prevailed in CPE on 11 June 2014, thereby excluding the .HOTEL Claimants from continuing through the process. The .HOTEL Claimants have argued that Mr. Krischenowski's exploitation of the portal issue that allowed parties to access confidential information of various applicants for new gTLDs, including information of several of the .HOTEL Claimants, coupled with Mr. Krischenowski's apparent business connections to HTLD, is cause for ICANN to cancel HTLD's .HOTEL application. ICANN's forensic investigation of the portal issue revealed that the user credentials of Mr. Krischenowski and his associates, Mr. Oliver Süme and Ms. Katrin Ohlmer, were responsible for numerous instances of suspected intentional unauthorized access to other applicants' confidential information, which occurred from March through October 2014. Mr. Krischenowski acknowledged that he accessed confidential information of other users, but denied that he acted improperly or unlawfully. Among other things, Mr. Krischenowski claimed that he did not realize the portal issue was a malfunction, and that he used the search tool in good faith. Mr. Krischenowski and his associates also certified to ICANN that they would delete or destroy all information obtained, and affirmed that they had not used and would not use the information obtained, or convey it to any third party. With respect to claims about Mr. Krischenowski's involvement with HTLD when he accessed the confidential information, ICANN has been informed that he was not directly linked to HTLD's .HOTEL application as an authorized contact or as a shareholder, officer or director. Mr. Krischenowski was a 50% shareholder and managing director of HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin), which was a minority (48.8%) shareholder of HTLD. ICANN has not uncovered any evidence that: (i) the information Mr. Krischenowski may have obtained as a result of the portal issue was used to support HTLD's application for .HOTEL; or (ii) any information obtained by Mr. Krischenowski enabled HTLD's application to prevail in CPE. HTLD submitted its application in 2012, elected to participate in CPE on 19 February 2014, and prevailed in CPE on 11 June 2014. Mr. Krischenowski's first instance of unauthorized access to confidential information did not occur until early March 2014; and his searches relating to the .HOTEL Claimants did not occur until 27 March, 29 March and 11 April 2014. Therefore, even assuming that Mr. Krischenowski did obtain confidential information belonging to the .HOTEL Claimants, this would not have had any impact on the CPE process for HTLD's .HOTEL application. Specifically, whether HTLD's application met the CPE criteria was based upon the application as submitted in May 2012, or when the last documents amending the application were uploaded by HTLD on 30 August 2013 – all of which occurred before Mr. Krischenowski or his associates accessed any confidential information, which occurred from March 2014 through October 2014. In addition, there is no evidence, or claim by the .HOTEL Claimants, that the CPE Panel had any interaction at all with Mr. Krischenowski or HTLD during the CPE process, which began on 19 February 2014. In furtherance of the Board's 10 March 2016 resolution directing ICANN's "President and CEO, or his designee(s), to complete the investigation of the issues alleged by the .HOTEL Claimants regarding the portal configuration as soon as feasible and to provide a report to the Board for consideration following the completion of that investigation" (see 10 March 2016 Board Resolutions, available at https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a ), ICANN informed HTLD of the .HOTEL Claimants' request that ICANN cancel HTLD's .HOTEL application, provided HTLD an opportunity to respond, and sought information from HTLD regarding its association with Mr. Krischenowski. In response, Mr. Philipp Grabensee, the now sole Managing Director of HTLD, confirmed for ICANN that at the time of the challenged conduct, Mr. Krischenowski was a 50% shareholder and managing director of GmbH Berlin, which was a minority (48.8%) shareholder of HTLD. Mr. Grabensee also confirmed that Mr. Krischenowski acted as a consultant for HTLD's application at the time it was submitted (in 2012), and that Mr. Krischenowski represented HTLD in three string confusion objections initiated by HTLD against applications by Despegar and Booking.com in 2013. Mr. Grabensee also stated that, in accessing the proprietary information, Mr. Krischenowski did not act on HTLD's behalf or in support of its application for .HOTEL. Mr. Grabensee noted that Mr. Krischenowski did not use HTLD's Login ID, did not inform HTLD's personnel about "his action," "did not provide any of the accessed information" to HTLD or its personnel, and HTLD "personnel did not have any knowledge about Mr. Krischenowski's action, and did not consent to it or approve it." Lastly, Mr. Grabensee noted the following recent changes to HTLD's relationship with Mr. Krischenowski: (i) the business consultancy services between HTLD and Mr. Krischenowski were terminated as of 31 December 2015; (ii) Mr. Krischenowski stepped down as a managing director of GmbH Berlin effective 18 March 2016; (iii) Mr. Krischenowski's wholly-owned company transferred its 50% shares in GmbH Berlin to Ms. Ohlmer (via her wholly-owned company); (iv) GmbH Berlin will transfer its shares in HTLD to Afilias plc; and (v) Mr. Grabensee is now the sole Managing Director of HTLD. The Board had the opportunity to consider all of the materials submitted relating to the .HOTEL Claimants' request for cancellation of HTLD's .HOTEL application. Following consideration of all relevant information provided and for the reasons set forth in the Resolution and Rationale, the Board has determined that cancellation of HTLD's .HOTEL application is not warranted, and the .HOTEL Claimants' request is therefore denied. The Board takes these claims seriously and the Board members have exercised independent judgment in making this decision, which it deems in the best interest of the organization and the community as a whole. The Board, however, does acknowledge that, based on the information available, Mr. Krischenowski may have taken some improper actions in relation to the portal configuration issue, and the Board is considering whether this conduct should be addressed directly with Mr. Krischenowski. This decision has no direct financial impact on ICANN and will not impact the security, stability and resiliency of the domain name system. This decision is an Organizational Administrative Function that does not require public comment. 3. Executive Session - Confidential: 1. Ombudsman FY16 At-Risk Compensation Whereas, the Compensation Committee recommended that the Board approve payment to the Ombudsman of his FY16 at-risk compensation. Resolved (2016.08.09.16), the Board hereby approves a payment to the Ombudsman of his FY16 at-risk compensation component. *Rationale for Resolution 2016.08.09.16* Annually the Ombudsman has an opportunity to earn a portion of his compensation based on specific performance goals set by the Board, through the Compensation Committee. This not only provides incentive for the Ombudsman to perform above and beyond his regular duties, but also leads to regular touch points between the Ombudsman and Board members during the year to help ensure that the Ombudsman is achieving his goals and serving the needs of the ICANNcommunity. Scoring of the Ombudsman's objectives results from both the Ombudsman self-assessment, as well as review by the Compensation Committee, with a recommendation to the Board. Scoring the Ombudsman's annual performance objectives is in furtherance of the goals of ICANN and helps increase the Ombudsman's service to the ICANN community. While there is a fiscal impact from the results of the scoring, that impact is already accounted for in the annual budget. This action will have no impact on the security, stability or resiliency of the domain name system. This is an Organizational Administrative Function that does not require public comment. 2. Officer Compensation Whereas, the attraction and retention of high caliber staff is essential to ICANN's operations and ICANN desires to ensure competitive compensation for staff. Whereas, independent market data provided by outside expert compensation consultants indicates that current and proposed increases to compensation amounts for the President, GDD, General Counsel & Secretary, CFO, COO, CIO, and SVP, Policy Development Support and General Manager, ICANNRegional Headquarters - Istanbul are within ICANN's target of the 50th to 75th percentile for total cash compensation based on comparable market data for the respective positions. Whereas, independent market data provided by outside expert compensation consultants indicates that current compensation for the CFO is below ICANN's target of the 50th to 75th percentile for total cash compensation based on comparable market data for the respective positions. Whereas, the compensation for the President, GDD, the General Counsel & Secretary, the CFO, and the SVP, Policy Development Support and General Manager, ICANNRegional Headquarters - Istanbul, has not been adjusted since an effective date of 1 July 2014. Whereas, the compensation adjustments for the COO and the CIO will establish better alignment with compensation review timeline of the other four Officers. Whereas, each Board member has confirmed that they are not conflicted with respect to compensation packages for any of ICANN's Officers. Resolved (2016.08.09.17), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of: (i) Akram Atallah, President, GDD; (ii) John Jeffrey, General Counsel & Secretary; and (iii) David Olive, SVP, Policy Development Support and General Manager, ICANN Regional Headquarters – Istanbul, in accordance with the independent study on comparable compensation, subject to a limitation that their annual base salaries for FY17 shall not increase by more than 6% for from their current base salaries. Resolved (2016.08.09.18), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Xavier Calvez, the CFO, in accordance with the independent study on comparable compensation, subject to a limitation that his annual base salary for FY17 shall not increase by more than 10% from his current annual base salary. Resolved (2016.08.09.19), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Susanna Bennett, the COO, in accordance with the independent study on comparable compensation, subject to a limitation that her annual base salary for FY17 shall not increase by more than 3% from her current annual base salary. Resolved (2016.08.09.20), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Ashwin Rangan, the CIO, in accordance with the independent study on comparable compensation, subject to a limitation that his annual base salary for FY17 shall not increase by more than 5% from his current annual base salary. *Rationale for Resolution 2016.08.09.16 – 2016.08.09.20* Attracting and retaining high caliber staff by providing a competitive compensation package is crucial to the organization. An improving job market will make more opportunities available for high caliber performers outside of ICANN. ICANN's President and CEO has requested that he be granted the discretion to increase the FY17 base salaries of: (i) the President, GDD, the General Counsel & Secretary, and the SVP, Policy Development Support and General Manager, ICANN Regional Headquarters - Istanbul) by up to 6% of their current base salaries; (ii) the CFO by up to 10% of his current base salary; (iii) the COO by up to 3% of her current base salary; and (iv) the CIO by up to 5% of his current base salary. The President and CEO has also informed the Board that he intends to also exercise the same discretion with respect to the other members of ICANN's Executive Team who are not Officers (which does not require Board approval). ICANN is in a critical phase that calls for continuity of certain skill and expertise, particularly with ongoing key projects including the New gTLD Program, Affirmation of Commitments and other organizational reviews underway, the U.S. Governments' IANA stewardship transition, expanding contractual compliance, and enhanced globalization efforts, among many others. Each of these projects requires knowledgeable and skilled executives to ensure ICANN's operational goals and objectives are met while ensuring that risk is mitigated to the greatest extent possible. Adhering to ICANN's employment philosophy, and providing competitive compensation, will help ensure these goals are achieved. It should be noted, however, that previously it had been discussed that the plan was to only seek authorization to increase relevant Officers' salaries every two years. Last year, the Board authorized the President and CEO to use his discretion to adjust the base salary of the two Officers whose current compensation had not been adjusted since they started working for ICANN. These adjustments were made effective 1 July 2015, which is the same date on which all other staff realizes their salary adjustments. In trying to better align the timing of compensation review and increases for all staff, it is being recommended that Officer's base salaries be reviewed for adjustment this year and each year hereafter. This is a change from the current two year Officer compensation review and adjustment cycle. Continuity and retention of key personnel during key organization phases is beneficial to all aspects of the organization. Thus, salary adjustments provided under this resolution likely will have a positive impact on the organization and its effort to fulfill its mission, as well as on the transparency and accountability of the organization. There will be some fiscal impact to the organization, but that impact will not have an effect on the overall current fiscal year budget and will be covered in the FY17 budget. This resolution will not have any direct impact on the security, stability and resiliency of the domain name system. This is an Organizational Administrative function that does not require public comment. Published on 11 August 2016 - You Tube <http://www.youtube.com/icannnews> - Twitter <https://www.twitter.com/icann> - LinkedIn <https://www.linkedin.com/company/icann> - Flickr <http://www.flickr.com/photos/icann> - Facebook <http://www.facebook.com/icannorg> - RSS Feeds <https://www.icann.org/en/news/rss> - Community Wiki <https://community.icann.org/> - ICANN Blog <https://www.icann.org/news/blog> Who We Are - <https://www.icann.org/get-started> - <https://www.icann.org/en/about/learning> - <https://www.icann.org/en/about/participate> - <https://www.icann.org/resources/pages/groups-2012-02-06-en> - <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> - <https://www.icann.org/presidents-corner> - <https://www.icann.org/en/about/staff> - <https://icann-openhire.silkroad.com/epostings/index.cfm?fuseaction=app.allp…> - <https://www.icann.org/en/news/newsletter> - <https://www.icann.org/development-and-public-responsibility> Contact Us - <https://forms.icann.org/en/contact> - <https://www.icann.org/resources/pages/customer-support-2015-06-22-en> - <https://www.icann.org/about/staff/security> - <https://www.icann.org/en/contact/pgp-keys> - <https://www.icann.org/contact/certificate-authority> - <https://www.icann.org/resources/pages/contact-f2-2012-02-25-en> - <http://forms.icann.org/en/about/aoc-review/contact> - <http://forms.icann.org/en/groups/reviews/contact> - <http://forms.icann.org/en/contact/speakers> - <https://www.icann.org/en/news/press> Accountability & Transparency - <https://www.icann.org/en/news/in-focus/accountability/mechanisms> - <https://www.icann.org/resources/pages/irp-2012-02-25-en> - <https://www.icann.org/groups/board/governance/reconsideration> - <https://www.icann.org/help/ombudsman> Governance - <https://www.icann.org/en/about/governance> - <https://www.icann.org/en/about/agreements> - <https://www.icann.org/en/about/aoc-review> - <https://www.icann.org/about/annual-report> - <https://www.icann.org/en/about/financials> - <https://www.icann.org/en/about/transparency> - <https://www.icann.org/en/about/planning> - <https://www.icann.org/dashboard> - <https://www.icann.org/en/news/rfps> - <https://www.icann.org/en/news/litigation> - <https://www.icann.org/en/news/correspondence> Help - <https://www.icann.org/en/help/dispute-resolution> - <https://www.icann.org/en/help/dndr> - <https://www.icann.org/en/help/name-collision> - <https://www.icann.org/en/news/announcements/announcement-06mar07-en.htm> - <http://whois.icann.org/> © 2016 Internet Corporation For Assigned Names and Numbers.Privacy Policy <https://www.icann.org/en/help/privacy>Terms of Service <https://www.icann.org/en/help/tos>Cookie Policy <https://www.icann.org/en/help/privacy-cookie-policy> Domain Name System Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."

2 1