January 2016 - Accountability-Cross-Community

Notes-Recordings-Transcript links for Ad Hoc Meeting, "Consumer Trust" in the Mission Statement - 11 January
by Brenda Brewer Jan. 11, 2016

Jan. 11, 2016

Hello all, The notes, recordings and transcripts for CCWG Ad Hoc Meeting, "Consumer Trust" in the Mission Statement held 11 January will be available here: https://community.icann.org/x/EKpYAw A copy of the notes may be found below. Thank you. Kind regards, Brenda Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. BBurr - History of this language. Was included in two place in Version 1 of the draft. Version 2 draft brought questioning if this was appropriate. Decision was made to take it out of the mission (given it was judged to be more about new gTLDs) and left in the review. ALAC and USCIB commented it should be re-inserted. Given this language in the original AOC was meant to focus on new gTLDs? given there is language which addresses this in other areas. There was also comment from the govt of the UK of this vs security and stability concerns. AGreenberg - Annex 9 omitted the discussion on consumer trust in the Bylaws. If the Bylaws covered this properly we would not be having this discussion. Given many people believe that the AOC commitment only applies to new gTLDs - if this is the case then according to ALAC it needs to be included regardless even if the definition of consumer trust is still un-agreed. MMueller - As to the first question the answer is no and the second with a yes. The second question is the source of my concern - once you remove this notion from the new gTLDs it then makes ICANN a consumer protection body. This would replace national regulatory orgs. responsibilities in this area which seems inappropriate. This change would be inconsistent with a tight mission. KArasteh - Mission needs to be precise and concise. Is this about where we put it or how we implemented. I prefer it not be included in the mission. GShatan - disagree with interpretation that para 3 is only tied to new gTLDs. We are clarifying the mission, and unless the AOC has been outside the mission for all these past years. ICANN needs to continue to honour the commitment in 3C and this needs to be in the Bylaws. BBurr - obviously a disagreement of reading of the3 AOC. However, the language would be in the Bylaws. GShatan - talking about 3C, where would this go. BBurr - In para 33 of rec. 9 annex. GShatan - no consumer trust in there. Need consumer trust in DNS space. Not putting it in would be a change. and should not only be for new gTLDs. BBurr - All of the provisions of sec. 3 are addressed in different parts of the Bylaws. AGreenberg - only talking about putting in article 1 on the Bylaws - no need to be in the mission. We are in the weeds - there is much clutter around such things but we are not cleaning those other points. This is not only about new gTLDs. Compliance has those words in it. MMueller - If it does not have to be in the mission then we are closer to agreeing. We already agreed that the key parts of the AOC were to go into the Bylaws. AGeenberg - What we are discussing commitments vs mission (the new sub-sections). MMueller - NCSG has always had issues with this AOC commitment which was a top down policy vs a bottom up policy. Our concern is knowing and limiting the mission to what is required to coordination on a global scale. There are many orgs which do consumer trust such as the OECD.I am a minimalist when it comes to the mission. BBurr - could you load the DelBianco document. SDB could you walk us through this. <https://community.icann.org/x/EKpYAw> https://community.icann.org/x/EKpYAw SDelBianco - I was convinced early that the consumer trust language should be ok by introducing AOC 9.3 into the Bylaws and is sufficient. I replied NO to both questions. There was a need to review the new gTLD program along the lines of consumer trust and competition. The Board was approached to define consumer trust, choice and competition. In Dec. 2010 the Board instructed to define these terms which took about a year. these definitions were approved by the Board. this establishes in a bottom up fashion we are capable of developing such things properly - and as such it is appropriate to transport AOC 9.3 into the review section of the Bylaws. BBurr - yes this is about new gTLDs. No one is opposed to consumer trust but not without proper definition otherwise it could leave ICANN open to issues. An undefined consumer protection requirement that is unbounded does not make sense. KArateh - we have to conclude on this at this meeting. AGreenberg - we need consumer trust for all names and not just new gTLDs. BBurr - are you proposing we include a new responsibility for ICANN on consumer protection. AGreenberg - This is about consumer trust not consumer protection. Just put the words of the AOC into the Bylaws. MMueller - I understand AG perspective. What Alan is missing is if you detach these words from the context of the new gTLDs then you create a generalized obligation, which is unclear what you gaining with this vs the risks that could be related to this. SDB seems satisfied. It is unclear why we need to detach this from its context. BBurr - the issue is unintended consequences could really arise to have untethered language which would be an expansion of ICANN's mission. Uncertain what is the difference between consumer trust and protection. GShatan - Section 3 AOC defines the responsibilities of ICANN and removing this responsibility implies changing the mission. The review is just one specific case of this. But if we want to remove it we should be honest about this. BBurr (chat) disagrees with this interpretation of AOC on this. AGreenberg - If we walk away from this we need to be honest and it is not this groups responsibility to decide if this should be included or not. BBurr - language was in the first draft but not in 2 and 3. We are not talking about walking away from anything. There are legitimate concerns about how this would be included properly in the Bylaws. Chris Disspain: We are only 'walking away' if we agree with your interpretation...in my interpretation you are over-reaching BBurr - I will summarize this discussion and circulate it so we can have more discussions. AGreenberg - If we are not including this language - where is this covered in the Bylaws. BBurr - lets take this back to the list. KArasteh - can we have a small summary? BBurr - We have two different perspectives on the language in the AOC 1 concept of consumer trust is specifically tied to the expansion of the gTLD space and requires a review to ensure this and those people are concerned about the unintended consequences of broadening this to all TLDs. The second veiw is that section 3 of the AOC is a general commitment and that it is inadequate to limit this to the expansion of the gTLD space and its review and that ICANN should have a general commitment to promoting consumer trust in the g space. The questions is does this broaden ICANN's scope or fail to include a key point. I will think about how to advance this. Would this require further work in WS2? SDelBianco - Definitions presented in the document were not meant to be included to the bylaws - they were just a reference. 3C convinces me its a chapeau because if this was a general requirement it would apply to even ccTLDs and this would not make sense. As such is a chapeau AGreenberg - I have no idea what was meant when it was written but things were changing when it was written in 2009. BBurr - same arguments as discussed above. We will stop here and get back to everyone on list. Conclusion. Documents Presented * <https://community.icann.org/download/attachments/56142352/Ad%20Hoc%20Meetin… tionDate=1452519329758&api=v2> Ad Hoc Meeting.pdf * <https://community.icann.org/download/attachments/56142352/Mission-definitio… ationDate=1452519343356&api=v2> Mission-definitions.pdf

1 0

Fwd: Additional input from RSSAC on CCWG Report
by Jordan Carter Jan. 11, 2016

Jan. 11, 2016

Not sure if this has made it to the list yet, J ---------- Forwarded message ---------- From: Verd, Brad <bverd(a)verisign.com> Date: 8 January 2016 at 23:11 Subject: Additional input from RSSAC on CCWG Report To: "leonfelipe(a)sanchez.mx" <leonfelipe(a)sanchez.mx>, "mathieu.weill(a)afnic.fr" <mathieu.weill(a)afnic.fr>, "rickert(a)anwaelte.de" <rickert(a)anwaelte.de>, " jordan(a)internetnz.net.nz" <jordan(a)internetnz.net.nz> Cc: Tripti Sinha <tsinha(a)umd.edu>, "rssac(a)icann.org" <rssac(a)icann.org> Dear CCWG-Accountability, Following its comment on 22 December 2015, the Root Server System Advisory Committee provides its proposal (below) to replace placeholder text with regard to the mission of ICANN as requested in the CCWG-Accountability third draft proposal. Best regards, Tripti Sinha and Brad Verd RSSAC Co-Chairs The Root Server System Advisory Committee, composed of the root server operators, root zone management partners, and others closely involved in the operations of the DNS root, has reviewed the Cross-Community Working Group (CCWG) Third Draft Proposal on Enhancing ICANN Accountability (Work Stream 1) and observed the ICANN community process that has led to it. The RSSAC notes that the CCWG-Accountability has added placeholder text with regard to the mission of ICANN (see page 8, Annex 5) awaiting RSSAC input. The RSSAC proposes the following bylaw change for the community’s consideration: Existing Bylaw: “The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is ... In particular, ICANN: … 2. Coordinates the operation and evolution of the DNS root name server system.” Proposed Change: “The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is ... In particular, ICANN: … 2. Facilitates coordination of the operation and evolution of the DNS root name server system." The RSSAC believes this proposed bylaw change reflects ICANN’s current role with respect to root server operators and the DNS root name server system. We appreciate your patience and consideration and welcome any further discussion. ###

4 3

Re: [CCWG-ACCT] Mission Statement
by Finn Petersen Jan. 11, 2016

Jan. 11, 2016

Seun: You are right – I forgot ”NOT”: So it should have been: “… With all respect – you are NOT answering the question! Sorry if I had not formulated the question properly. …” Thx! Best, Finn Fra: Seun Ojedeji [mailto:seun.ojedeji@gmail.com] Sendt: 10. januar 2016 21:57 Til: Finn Petersen Emne: Re: [CCWG-ACCT] Mission Statement I guess you meant NOT answering the question. Cheers! On 10 Jan 2016 9:52 PM, "Finn Petersen" <FinPet(a)erst.dk<mailto:FinPet@erst.dk>> wrote: Milton, With all respect – you are answering the question! Sorry if I had not formulated the question properly. So let me try again. Is there, in your view, any kind of GAC advice that today (with the current Mission Statement) is within ICANN’s mission, but that in the future with the revised Mission Statement as defined in the CCWG 3rd draft report would be outside the revised mission for ICANN, so that the Board does not have the possibility any longer to take the advice into account? I hope the question is clearer now. There are only two possible answers: yes or no! Best, Finn Fra: Mueller, Milton L [mailto:milton@gatech.edu<mailto:milton@gatech.edu>] Sendt: 8. januar 2016 23:18 Til: Finn Petersen; accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org> Emne: RE: Mission Statement Finn, From our latest exchanges regarding the new Mission Statement and as stated in the chat yesterday, DK is of the view that the Board can of course only take decisions based on GAC advice that is within the ICANN’s mission. MM: Thank you for that. But what we have been seeking is a clear answer to see if the proposed changes to the Mission Statement would imply that the Board in the future would be further constrained in taking GAC advice into account. MM: Well, it depends on the advice, doesn’t it? I understood from Becky during our CCWG call yesterday, “that ICANN should be able to continue to accept and implement GAC advice as it has been”– in other words the Board will have the same possibility to take into account GAC advice in the future (after the IANA transition) as the Board has today. If that is the case, I would think that it is now crystal clear to me. MM: As above, if GAC advises ICANN to do things that are outside its mission you can expect challenges. _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Recommendation 2 - Escalation Timelines - 1st reading conclusions
by Alice Jansen Jan. 11, 2016

Jan. 11, 2016

Sent on behalf of CoChairs Please find below the main conclusions of our deliberations during call #75. The updated document is attached. 1. Address concern expressed by many that escalation timelines are too tight and aggressive by simplifying some decision steps in the process, while ensuring that the issues remain widely discussed within the Community. a. Jordan Carter is tasked to make a proposal along these lines (Note: Text in yellow highlights below should be considered “Pending proposal from Jordan Carter to adjust”) b. Make it mandatory for petitioning party to reach out to SO/ACs to socialize relevant information before Community Forum. c. Removing the mandatory community conference call will allow for extension of timeline if so requested by an SO or AC. Additionally, should the petitioning group need a call, ICANN will provide resources upon request. 2. Acknowledging concern raised by ALAC and others regarding the thresholds adjustment in case the number of Decisional Participant is lower (paragraph 62 – page 12), the group is considering the option to lower the requirement of support for Fundamental Bylaw change only. a. Since the Fundamental Bylaw change process is a requirement for “approval” and not a “rejection” option, this would preserve the requirement for stronger protection of Fundamental Bylaws. (see page 11) b. Note was made that this approach was still raising some concerns 3. The use of percentage for thresholds can be suggested as guidelines for discussion basis in the event of the creation of new SO/ACs but there would need to be a conscious decision, depending on the circumstances. a. Clarify that if such a new SO/AC were to become a decision participant in the Empowered Community, this change would follow the Fundamental Bylaw change process Second reading is planned for Thursday, 14 January. Best regards Mathieu, Thomas, León

1 0

Mission Statement
by Finn Petersen Jan. 10, 2016

Jan. 10, 2016

Dear CCWG, >From our latest exchanges regarding the new Mission Statement and as stated in the chat yesterday, DK is of the view that the Board can of course only take decisions based on GAC advice that is within the ICANN's mission. But what we have been seeking is a clear answer to see if the proposed changes to the Mission Statement would imply that the Board in the future would be further constrained in taking GAC advice into account. I understood from Becky during our CCWG call yesterday, "that ICANN should be able to continue to accept and implement GAC advice as it has been"- in other words the Board will have the same possibility to take into account GAC advice in the future (after the IANA transition) as the Board has today. If that is the case, I would think that it is now crystal clear to me. I just want be to be assured that nobody in the CCWG is going to object to this conclusion. If that is the case - then I will rest my case! If the answer is no, please specify how the Board would be further constrained in taking GAC advice into account after the transition. Best, Finn Kind regards Finn Petersen Director of International ICT Relations DANISH BUSINESS AUTHORITY Langelinie Allé17 DK-2100 Copenhagen Ø Telephone: +45 3529 1000 Direct: +45 3529 1013 Mobil2: +45 2072 7131 E-mail: FinPet(a)erst.dk<mailto:FinPet@erst.dk> MINISTRY FOR BUSINESS AND GROWTH

7 9

Re: [CCWG-ACCT] "Consumer Trust" in the Mission Statement
by Steve DelBianco Jan. 10, 2016

Jan. 10, 2016

Our recommendation #9 is Incorporating the Affirmation of Commitments in ICANN’s Bylaws. That includes commitments made by ICANN in the AoC, such as the commitment cited by Becky, to "promote competition, consumer trust, and consumer choice in the DNS marketplace." First, I don’t think we should casually discard any of those three commitment items just because it is difficult to define. The AoC review that’s just begun will develop working definitions as part of its review. I would answer 'No' to both of Becky’s questions. This commitment does not need to be part of Core Values, and could live in the bylaws section describing the required AoC review of any expansion of new gTLDs. Since it is in the bylaws, ICANN’s fulfillment of this commitment could be the subject of an IRP. And any changes to this commitment would be subject to veto by the empowered community. From: <accountability-cross-community-bounces(a)icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Becky Burr <Becky.Burr(a)neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: Friday, January 8, 2016 at 2:10 PM To: Accountability Community <accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] "Consumer Trust" in the Mission Statement As discussed in our call yesterday, we would like to get some discussion started on some of the issues with the Mission Statement, Commitments & Core Values elements of the CCWG Proposal. One of those issues relates to the inclusion of the concept of promoting “consumer trust” in the Commitments and/or Core Values. The USCIB comment, for example, urged inclusion of a Commitment/Core Value of “promoting competition, consumer trust, and consumer choice in the DNS marketplace.” ALAC urged inclusion of the consumer trust language. This is the topic we will discuss on Monday, during the Ad Hoc meeting just announced. Feel free to contribute your views in this thread, particularly if you are not going to be able to participate on Monday. ISSUE: Paragraph 3 of the Affirmation of Commitments describes the goals of the AoC, saying: "This document affirms key commitments by DOC and ICANN, including commitments to: … (c) promote competition, consumer trust, and consumer choice in the DNS marketplace….” Paragraph 9.3 of the AoC says: … If and when new gTLDs (whether in ASCII or other language character sets) have been in operation for one year, ICANN will organize a review that will examine the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust and consumer choice …. ICANN will organize a further review of its execution of the above commitments two years after the first review, and then no less frequently than every four years. In the Initial Draft Proposal, this AoC language was transposed into the Core Values by requiring ICANN to depend “on market mechanisms to proote and sustain a healthy competitive environment in the DNS market that enhances consumer trust and choice.” (Para 107, page 27 Initial Draft Proposal) In the 2nd Draft Proposal we elected to delete the reference to consumer trust in the Mission statement and include it in the Review section of the Bylaws (See 3rd Report, Appendix 9, Para. 33). The reason we agreed to make this switch was because it is not a standalone ICANN commitment in the AoC, rather, it is specifically tied to new gTLD expansion and specifically tied to a required review. Several commenters in both the 2nd and 3rd comment round argued that the Core Values should specifically call out consumer trust. Some have disputed my characterization of Paragraph 3 of the AoC (i.e., it states the goals of the AoC but does not recite a specific commitment), on the grounds that my characterization is an opinion and not a fact. QUESTIONS: Should an AoC provision specific to TLD expansion be leveraged to impose generalized, independent, and affirmative competition and consumer trust protection obligations on ICANN? Does ICANN’s fundamental Mission to ensure “stable and secure operation” of the DNS, and its various Commitments (i.e., to use processes that enable competition, and to preserve stability, reliability, security, global interoperability, resilience, and openness) adequately address this concern? J. Beckwith Burr Neustar, Inc./Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office:+1.202.533.2932 Mobile:+1.202.352.6367 /neustar.biz<http://www.neustar.biz>

4 3

Re: [CCWG-ACCT] DOCUMENT - Recommendation 2 Escalation timeframe (first reading)
by Alan Greenberg Jan. 10, 2016

Jan. 10, 2016

I agree that the process could be simplified. Merging the petition and conference call might be possible, but it would have to be done with care to ensure that there is proper time to "socialize" the need to exercise the power, or we will never get the critical mass needed. It is important that the other AC/SOs (those who did not originate the petition) have a proper opportunity to consider the issue and ensure that their community participates in the Community Forum. If they don't they will not likely support the final action. On changing the numbers to percentages, I personally think that the numbers should be a conscious decision at the time the number of AC/SOs is increased, but the percentages would provide good guidelines, and I suspect I could live with them as defaults. They seem to work as the number increases from 5. They do NOT work if you decrease below 5 participating. I have attached a PDF of a spreadsheet showing the calculations. Alan At 06/01/2016 12:06 PM, Jordan Carter wrote: >Hi all > >Just a couple of general comments. > >On the timeframe concern, I think we face a hard >juggle to keep the times reasonably tight on the >one hand (so things don't drag where a power >should be used), and making sure the powers are actually workable. > >If we have to lengthen the times for any steps I >think we should look for ways to not see the >total timeframe to use a power blow out. > >My primary proposal to achieve that is to merge >the petitioning and conference call steps. I >wasn't able to be part of the discussion about >the escalation process in Dublin because I was >detained on other small groups, but I never >supported adding another step to our quite clean >"Petition, Forum, Decision" model from the second draft. > >So if we were to go ahead in this way, an SO or >AC would decide to petition to use the power. If >that petition was successful, according to its >own rules, a Community Forum would be organised. > >I think we are clearer than we were at one point >that the Community Forum isn't a chance for >travelling and getting together in person: it's >an online Adobe meeting, which is highly unlikely ever to take one day or two. > >In other words, having both a Conference Call >and a Community Forum essentially duplicates the >same thing, with no benefit that is entirely obvious. > >Merging the two steps will help avoid a time frame blowout. > >I can't recall whether or not we had said more >than one SO or AC needed to petition to use a >power but we could use the same threshold as >required to hold a Forum, in merging the steps. > > > >On changing the #s to %s in the decision table, >I don't know how workable this is - it risks >unintentionally creating too-high thresholds or >too-low ones, given the low number of SOs and >ACs involved. I think I would prefer to stick >with numbers, and adjusting them should the >numbers of SOs or ACs change in future, but >don't have a strong view about that. > > >Hope this helps. > > >cheers >Jordan > > > >On 6 January 2016 at 15:55, Alice Jansen ><<mailto:alice.jansen@icann.org>alice.jansen(a)icann.org> wrote: >Sent on behalf of CCWG-ACCT Co-Chairs >In preparation for your Recommendation 2 >Escalation timefframe (first reading) discussion >scheduled for your call #75 - Thursday, 7 >January 2016 (19:00 22:00 UTC) - please find >attached thee material to review. >Please use this email thread to circulate any >comments you may have in advance of the call. >Thank you >Mathieu, Thomas, LeÃ³n >_______________________________________________ >Accountability-Cross-Community mailing list ><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org > >https://mm.icann.org/mailman/listinfo/accountability-cross-community > > > >-- >Jordan Carter > >Chief Executive >InternetNZ > >+64-4-495-2118 (office) | +64-21-442-649 (mob) >Email: <mailto:jordan@internetnz.net.nz>jordan(a)internetnz.net.nz >Skype: jordancarter >Web: <http://www.internetnz.nz>www.internetnz.nz > >A better world through a better Internet > >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community

2 1

Re: [CCWG-ACCT] "Consumer Trust" in the Mission Statement
by Alan Greenberg Jan. 9, 2016

Jan. 9, 2016

Before my substantive reply to this thread, I note that the text on the AoC Review on Promoting Competition, Consumer Trust, and Consumer Choice (CCTCC) seems to have been omitted from Annex 9 (between the SSR review starting at para 98 and the Whois review starting at para 112 (which should be in bold), jumping from Review 2 to Review 4). Since no one seems to have noticed, I have to wonder what else was lost in this revision? If the text for this review had been there, it would have said (taken from the 2nd draft proposal) "566 ICANN will ensure that as it expands the Top-Level Domain (TLD) space, it will adequately address issues of competition, consumer protection, security, stability and resiliency, malicious abuse issues, sovereignty concerns, and rights protection." and "569 This Review will examine the extent to which the expansion of gTLDs has promoted competition, consumer trust, and consumer choice, as well as effectiveness of:" Clearly this review is focused on the EXPANSION of the namespace. However, the vast percentage of names in use now and probably for the foreseeable future are not associated with the expansion. Omitting the issue from the core serves to disenfranchise the consumers who use those names (that is, the bulk of all Internet use). I agree with those who say that the term may be hard to define, quantify and measure. That is true with many things we value in life. But it does make them less important. Regardless, the term is used twice in the Whois Review section of the proposed Bylaws as well as in the missing CCTCC section. The lack of a definition does not preclude its use there and certainly we cannot omit the expression in a wholesale manner because of the lack of a definition or metrics. We have said that much of what we are doing in in this CCWG is not to control the current Board or management, but to ensure that as time goes forward, we can ensure that veer off course. This is exactly such a situation. The formal Mission of Contractual Compliance is "To preserve the security, stability and resiliency of the Domain Name System and to promote consumer trust." (https://www.icann.org/resources/pages/about-2014-10-10-en) In the past, Compliance has been accused of only enforcing certain aspects of its contracts and specifically not the parts that would often impact consumers (such as Whois issues and issues related to improper domain name transfers or hijacking). Thankfully that is no longer the case, but we need to ensure that the "bad old times" do not return. Capturing the concept of consumer trust in ICANN's mission is exactly how we can do so. The Contractual Compliance mission statement can be changed at will with no notice or community consultation. Embedding the concept in ICANN's mission provides the protection that is needed. Alan At 09/01/2016 12:12 PM, Kavouss Arasteh wrote: >Steve, I tend to agree with Malcolm in saying >that whenever, we do not have a xclear >definition nor a descrition for an item what is >the usefulness of its inclusion in BYLAWS ? >The difficulties that I have is , we may include >many thing in the Mission and/or Bylaws, but >when ICANN wants / required to implement that >it would face difficulties to do so. Even if >ICANN claims that it has had implemented, it is >difficult to check the validity of that claim. >Regards >Kavouss > >2016-01-09 14:16 GMT+01:00 David Post ><<mailto:david.g.post@gmail.com>david.g.post(a)gmail.com>: >I do not think that the addition of this >language is a good idea. Lengthening the list >of 'values' and 'commitments' that ICANN is >supposed to implement will inevitably weaken the >Mission Statement. The more the document >suggests that it is ICANN's job to balance a >wide variety of different concerns - enhancing >competition and consumer choice, supporting >geographic and cultural diversity, promoting >human rights and the global public interest - >the easier it becomes for ICANN to justify >pretty much anything it might do in the future >as promoting one or another of these broad >goals. The point that Andrew Sullivan made >recently in connection with the discussions >about the GPI is applicable here, I think: > >"ICANN should pay attention to its >well-understood and needed functions. It should >not go adventuring out into global governance issues that >distract from that narrow set of >responsibilities. And it should not embrace >language that distracts from the narrow responsibilities -- >lest such language become an attractive nuisance >that encourages people to think ICANN has power it never has had" > >David > > >At 04:10 PM 1/8/2016, Burr, Becky wrote: > >> As discussed in our call yesterday, we would >> like to get some discussion started on some of >> the issues with the Mission Statement, >> Commitments & Core Values elements of the CCWG >> Proposal. One of those issues relates to the >> inclusion of the concept of promoting >> âconsumer trustâ in the Commitments and/or >> Core Values. The USCIB comment, for example, >> urged inclusion of a Commitment/Core Value of >> âpromoting competition, consumer trust, and >> consumer choice in the DNS >> marketplace.â ALAC urged inclusion of the consumer trust language. >>This is the topic we will discuss on Monday, >>during the Ad Hoc meeting just announced. Feel >>free to contribute your views in this thread, >>particularly if you are not going to be able to participate on Monday. >> ISSUE: Paragraph 3 of the Affirmation >> of Commitments describes the goals of the AoC, saying: >> "This document affirms key >> commitments by DOC and ICANN, including >> commitments to: (c) promote competition, >> consumer ttrust, and consumer choice in the DNS marketplace.â >>Paragraph 9.3 of the AoC says: >> If and when new gTLDs (whether in >> ASCII oor other language character sets) have >> been in operation for one year, ICANN will >> organize a review that will examine the extent >> to which the introduction or expansion of >> gTLDs has promoted competition, consumer trust >> and consumer choice . >ICANN will organize a >> further review of its execution of the above >> commitments two years after the first review, >> and then no less frequently than every four years. >> In the Initial Draft Proposal, this >> AoC language was transposed into the Core >> Values by requiring ICANN to depend âon >> market mechanisms to proote and sustain a >> healthy competitive environment in the DNS >> market that enhances consumer trust and >> choice.â (Para 107, page 27 Initial Draft Proposal) >> In the 2nd Draft Proposal we elected to >> delete the reference to consumer trust in the >> Mission statement and include it in the Review >> section of the Bylaws (See 3rd Report, >> Appendix 9, Para. 33). The reason we agreed >> to make this switch was because it is not a >> standalone ICANN commitment in the AoC, >> rather, it is specifically tied to new gTLD >> expansion and specifically tied to a required review. >> Several commenters in both the 2nd >> and 3rd comment round argued that the Core >> Values should specifically call out consumer >> trust. Some have disputed my characterization >> of Paragraph 3 of the AoC (i.e., it states the >> goals of the AoC but does not recite a >> specific commitment), on the grounds that my >> characterization is an opinion and not a fact. >>QUESTIONS: >>Should an AoC provision specific to TLD >>expansion be leveraged to impose generalized, >>independent, and affirmative competition and >>consumer trust protection obligations on ICANN? >>Does ICANNâs fundamental Mission to ensure >>âstable and secure operationâ of the DNS, >>and its various Commitments (i.e., to use >>processes that enable >>competition, and to preserve >>stability, reliability, security, global >>interoperability, resilience, and openness) adequately address this concern? >> >> >>J. Beckwith Burr >>Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer >>1775 Pennsylvania Avenue NW, Washington D.C. 20006 >>Office: >><tel:%2B1.202.533.2932>+1.202.533.2932 Mobile: >><tel:%2B1.202.352.6367>+1.202.352.6367 / <http://www.neustar.biz>neustar.biz >>_______________________________________________ >>Accountability-Cross-Community mailing list >><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org >>https://mm.icann.org/mailman/listinfo/accountability-cross-community > >******************************* >David G Post - Senior Fellow, Open Technology Institute/New America Foundation >blog (Volokh Conspiracy) ><http://www.washingtonpost.com/people/david-post>http://www.washingtonpost.com/people/david-post >book (Jefferson's >Moose) ><http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0>http://tinyurl.com/c327w2n > >music ><http://tinyurl.com/davidpostmusic%A0>http://tinyurl.com/davidpostmusic >publications etc. http://www.davidpost.com >******************************* > >_______________________________________________ >Accountability-Cross-Community mailing list ><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community > > >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community

2 1

DOCUMENT - Recommendation 1 – Inspection Rights (first reading)
by Alice Jansen Jan. 8, 2016

Jan. 8, 2016

Sent on behalf of CCWG-ACCT Co-Chairs In preparation for your Recommendation 1 – Inspection Rights (first reading) discussion scheduled for your call #75 - Thursday, 7 January 2016 (19:00 – 22:00 UTC) - please find attached the material to review. Please use this email thread to circulate any comments you may have in advance of the call. Thank you Mathieu, Thomas, León

13 12

Notes-Recordings-Transcript links for CCWG ACCT Meeting #75 - 7 January
by Brenda Brewer Jan. 8, 2016

Jan. 8, 2016

Hello all, The notes, recordings and transcripts for CCWG ACCT meeting #75 - 7 January will be available here: https://community.icann.org/x/qpRlAw A copy of the notes may be found below. Thank you. Kind regards, Brenda Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. 1. Welcome, Roll-Call, SoI TR (2 min) * No one on dial only - no changes to SOI. 2. Recommendation 1 - Inspection rights MW (45 min) See: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0… * MWeill - ICANN concern this could consume extraordinary amount of resources. We have also received a memo from the lawyers on this topic - relevant extracts have been included in the above noted document. Firstly scope and limitation of inspection rights. Secondly criteria for deciding to use the inspection - Sole Designator. Thirdly which is not related to inspection is the admissibility of the GAC to the Empowered community. * MWeill - Our lawyers have advised as to which documents inspection rights apply to. These could be included in our report and could address some of the concerns from the Board. Are there any issues with this regarding the scope and limitation. Support in the chat. * BTonkin - requirement for more clarity given the basic accounting GL information would not be helpful. In trying to provide additional information to be useful but needs to be framed so it is not unlimited. * MWeill - Adding recommendations from the lawyers would seem to meet some of the requirements. * BTonkin - need to look at this not from the POV of a California court but rather from an IRP panel - needs to definition of terms. Best approach may be for the Board to provide some suggested red-line text to be clear. * MWeill - Second issue - Thresholds for making a request - The third draft proposed that the SD would submit a request requested by a single SOAC. Board requested standard support level similar to the thresholds for other powers. * JCarter - The lawyers position seemed more reasonably which did not require a high threshold vs what the Board require. * AGreenberg - Answer to this depends on what there is a right to request - so the two issues are related. My position is between the Board and JC's position. It is not reasonable, personal opinion, allowing a single SOAC to request. Cal law is clear that this should not be for business interests. Would need at least 2 SOACs to approve. Board is overreacting but the current proposal is overly liberal and open to abuse. * JCarter - supports lawyers position on principal. This is not really a power, it is the result of the compromise for moving away from membership. Disagree with AG that this will be abused by the gNSO given their internal processes. * EMorris - Agree with JC. Need to keep things simple so it can be used and not allow it to be twisted by the Board or staff to delay or block requests. Similarly for who can make a request. DIDP request example. Making it too complicated is not useful. * MWeill - comment by Holly - Holly J. Gregory (Sidley): if requested information is reasonable related to a community power or right, Alan's concern about improper use of inspection rights to obtain commercial information is addressed * GShatan - Follow on Holly - AG's concerns may be misreading counsel comments on this. gNSO is not made up of single intent group. Gaining commercial advantage via this information should not be allowed. * MWeill - space is already pretty narrow. * CChalaby - Board sees it as a community power vs a designator power. As such using the standard thresholds would make sense. On fraud or mismanagement a third party could be hired to make the determination if there was fraud or mismanagement. * MWeill - The proposed investigation power proposed by the Board is good and should be noted in our proposal. CC are things clear. * CChalaby - heard but it does not seem that the standard thresholds should apply. * BTonkin - The example EM gave was instructive. Accounts will tell you how much we paid a supplier vs a document inspection right which could show if a contractor has met the requirements of the contract. So standard financial records it could be ok to have a single SO or AC. For anything more complex a higher threshold. * MWeill - This sounds like an interesting way forward. * HGregory - interpretation of our advice has been correct. There may be confusion on what is covered by inspection rights which does not cover investigations. We were simply trying to match what members would be allowed under Cal. law. * KArasteh - (no sound) * MWeill - different levels of requests would require different approval. * SDBianco - discussion of sole member vs sole designator - thresholds would of applied to the sole member so this is consistent. If we had a sole member we would be having the same discussion. * MWeill - will update the document to reflect low thresholds for accounting records and then include higher thresholds for investigations and include restrictions for vexatious or frivolous request in implementation should be allowed to be dismissed. * MWeill - not allowing the GAC to be a decisional member. Until we receive formal GAC input on this we should not discuss this at this point but rather once GAC input has been received. * RGross - Caution if we have before NTIA and Congress if we present a proposal with the GAC being a decisional participant. which could undermine the transition. Also consider rec. 11. * MWeill - This discussion will be taken up at a later meeting. * KArasteh - We must wait for the GAC to take a position. There is a big difference bet rec. 1 and rec. 11. * MWeill - The inspection rights are as discussed here. DIDP is not a community power and is available to all. This concludes this section. 3. Recommendation 2 - Escalation timeframe LS (45 min) See: <http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0…> http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0… Discussion points: * Notice and opportunity to comply extend periods * Extension of deadlines * Empowerment of Councils or Charis for the initial steps * Removal of certain process steps (simplification) * JCarter - 15 day deadlines originally proposed with few steps. Dublin increased the number of steps substantially. Keeping deadlines short may not allow the use of such powers. Overextending the timelines may imply its too long to be of any use. The proposal in the document offers 4 options as noted above. Having examined these it seems that merging the conf. call and forum steps and extend deadlines. This could allow for extending timelines to 30 days. * LSanchez - Opens to questions and comments * AGreenberg - Empowerment of councils in unclear. Re merging the levels no major issues except, need to specify reasonable processes to socialize the intent to use a power. * LSanchez - way forward is to include a requirement to socialize any proposed use of a power in the next draft. We could also include JC's proposal for discussion in the next call. * LSanchez - ALAC objection to threshold adjustment proposal - AG should present. * AGreenberg - Clarification objected only for the Board removal. ALAC was ok for approving changes to fundamental Bylaws. Board removal is as revolutionary as you can get. It generates issues which make no sense especially if it allows 3 SOACs to remove the Board. * TBenJemaa - Removing the Board is dramatic - and there is no need to reduce the threshold. 3 is not acceptable. Also for other powers. The reduction proposal is not acceptable. Original version was better. * ASullivan - concerned trying to apply a 3 value system to a 2 value decisions system. I do not care how this works out - if people can abstain then you have to adjust accordingly. * JCarter - The scenario that gave rise to this was not an abstention - the issue was trying to deal with an SOAC that cannot decide (but we have not defined what counts as an abstention vs not participating). In this case it ends up requiring unanimity for using a power which is against the base principles of the CCWG. * SDelBianco - explanation from Dublin, need strong support in absence of clear objections. SOACs have 4 options, support, against, abstain or just communicate to the community. * AGreenberg - RE JC comment - we should not psychoanalyze SOAC if they have no answer. Similar comment. Unrealistic that if someone says no they could enable the action to go forward. * JCancio - unfortunate we are discussing the participation of the GAC. Remind everyone this is about the exercise of community power and this is only sensible if supported by the community at large - so lowering thresholds is not good and would undermine this exercise. * MWeill - Useful debate - threshold on fundamental bylaws could paralyze the company, and it is special because it is special given it is an approval vs a veto. We could simply lower fundamental bylaw approval thresholds. this could be a way forward. * TBenJemaa - are we reconsidering the Dublin? this should not happen. Abstention is participation. Thresholds have to be kept as per Dublin. * Seun - Supports TBJ and give rationale - we have recall to SOACs have their own processes to reach agreement. We should avoid reducing thresholds and am in favour of unanimity to remove the entire Board. Fundamental Bylaw is critical and threshold should not be reduced. Participation by GAC - why is this still an issue. * LSanchez - going forward co-chairs will redraft with the proposed amendments by MW and test this on the list to understand if this is acceptable to the CCWG. * LSanchez - Board suggestion regarding the changing of the number of SOACs. * BTonkin - The concept is that ICANN may involve in the future - as such it would be prevent uncertainty. * AGreenberg - I have distributed a chart showing the Board proposal if there is a decrease will not work. Adding units may really depend on circumstances. We should not cast in concrete needs to be a case by case, it should be a guideline. * JCarter - Agree with AG. We will have to consider anyways given adding a new SOAC will require a change of Bylaws. * TBenJemma - agree with AG but also agree with Board that it has to evolve with the changes. * LSanchez - co-chairs will draft recommendation based on the discussion and circulate to consideration by the CCWG. * SdelBianco - in considering adding SOAC implies a change in Bylaws but a change of thresholds are a fundamental bylaw and require approval by the Designator. * Lsanchez - reasonable and to be taken into account at time of drafting. * LSanchez - Is this approach in line with the concerns of the Board? * BTonkin - will consider the written text early next week. * LSanchez - concern of = weight between SO and ACs. Still waiting on input from gNSO on this - as such would recommend this be a pending issue and discuss it when the gNSO input is received so all comments can be concerned. * LSanchez - this concludes this section and we can go to the Break. Post break notes. 4. Recommendation 4 - Budget (IANA) TR (45 min) See: <http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0…> http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0… TRickert - subjects: 1. Confirm clarifications requested by CWG regarding transparency, rationale and role of CWG Stewardship in elaborating a process for IANA Budget (see pages 5 and 6) 2. Discuss and refine role of operational communities in IANA Budget veto power as suggested by ICANN Board and taking into account IAB specific input (IAB does not want "a direct voice in the budget, either regularly or on its rejection") (see page 6, paragraph 22) 3. Discuss whether to provide clearer guidelines on caretaker budget or leave it to implementation (Draft Report was mentioning that details are "under development") 4. Discuss input regarding inclusion of Budget power as a Standard (instead of Fundamental Bylaw) (as suggested by NiRA, AFTLD) * Trickert - On the first point, this was included in the second draft but unfortunately not carried over to the third draft. As such we propose to simply re-introduce the text from the second version. * Seeing no objection this will be carried forward. * TRickert - On the second point - IANA Budget Veto. Note from IANA says it does not wish to participate in a Budget veto. (reads suggested text in the above document). * AGreenberg - Comment, should the IANA budget be vetoed it is of concern to all of the community and not just the operational community. As such do not agree with the Board recommendation. * IOkutani - The ASO believes the third version of the CCWG proposal meets the needs of the ASO. The fees are adequately addressed by the SLA bet. ICANN and the ASO. This element of the proposal should not block the transition. * JCarter - originally thought this was useful comment by the Board. In WP1 this was not of interest. Also the IAB and ASO positions it would seem the third draft would be acceptable. Agree with AG. * ASullivan - uncomfortable with para. 22. The relationship bet the IETF and ICANN is managed by the IAB on the IETF side and the IAB does not want to participate in budget discussions because they have an SLA for services. The IAB suggested a different approach in the second draft - that the budget of the IANA operation be frozen over a fixed period. For us this is a straightforward supplier service agreement. * TRickert - AS how can we reword to satisfy the IAB. * ASullivan - need to to consider contractual commitments. * CChelaby - Board perspective - the idea agrees with the work on the budget - but IANA is a service to customers so it made sense to have those communities oversee this. Takes note of AG comments. Comfortable with proposal para 22 and removing IETF/IAB. * KArasteh - the only non-SO is IETF - other communities must be involved beyond the operational communities * BTonkin - The last sentence is the key and may have to improved. Have to understand how the caretaker budget functions. Elaborating further that allows it to deliver on its contracts and SLAs and services for the security and stability of the Internet. * TRickert - the essence of para 22 seems ok but needs some finessing as per the discussion above. The next draft should go to the mailing list. * TRickert - Thrid point - caretaker budget - more details in the proposal or leave it to implementation? JC to provide background. * JCarter - not much to add. there has been good discussions and the principles are solid. There is not much difference between the options. No view on either option. JZ? * JZuck - principles are mostly agreeable for the community. Agree with JC much of this is going to be technical and such be left to implementation. * TRickert - we are doing the third question under budget. * CLangdon-Orr - for those not involved in CWG work, there is DT0 which is working on the caretaker budget. Leave the details to implementation - which the CWG is currently working on. * CChelaby - Agree with JZ, and the proposal, caretaker budget should be part of the fundamental bylaw which was included in the Board comments. * JZuck - need to not have too many details in the bylaws. but high level is fine. * CChelaby - makes sense. * TRickert - it seems clear this is fit for implementation with the amendments as per the above discussion. * TRickert - 4th point - Fundamental vs standard bylaw - Strong wish from the Board for fundamental. Also CWG requirement makes this a requirement for a fundamental bylaw. Additionally this has always been presented as a fundamental bylaw. As such it would not seem advisable to make it a standard bylaw. Would like to hear from those wanting a standard bylaw. * AGreenberg - changing now does not seem wise. * Trickert - this would close this section. 5. Recommendation 5 - Mission MW (45 min) refer to public comment summary - Presentation: <https://community.icann.org/x/qpRlAw> https://community.icann.org/x/qpRlAw Deck Meeting #75 Mission Statement * MWeill - I will hand it over to Becky to deliver her presentation. * BBurr - presentation of the slides - Straw men/persons: * GAC Advice, PICs, Contract Provisions: Questions * In what way does/should ICANN's Mission Statement constrain the Board's ability to comply with GAC Advice? * Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement. * How does/should the Mission Statement limit the permissible scope of ICANN's agreements with contracted parties? * Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission. * GAC Advice, PICs, Contract Provisions: Questions * Who should be able to challenge whether or not a contract provision is in "service of" that Mission, and under what circumstances? * To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern? * If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary? * Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis. * Contracting and Regulatory Prohibition: Questions * The ICANN Board asserts that the prohibition on regulation of services that use the Internet's unique identifiers, or the content that such services carry or provide is "not appropriate for inclusion of the Mission Statement." The Board further suggests that the CCWG should direct the Bylaws drafting team to incorporate limitations on the reach of Registry and Registrar contracts in another part of the Bylaws. * Where? GNSO Section? General Provisions (Article XV)? * Include challenge mechanism to test voluntariness? * Impact of this change? * KArasteh - Did the GAC identify any limitation of ICANN accepting GAC advice. Suggest there should be language to accept requirements of GAC. Second question ICANN Board proposes mission should be precise and concise - rest should go to scope etc. - is there a proposal how to do this. * BTonkin - Board did not object on GPI - Board has simply stated they will need to consider GPI if their concerns are not addressed. Also yes we need a specific mission. gTLD specific issues should probably be in the gNSO. The other parts can be included in the respective parts. * AGreenberg - on consumer trust - AOC text on this is only an interpretation, and ALAC feels this is important. Much of the policies should be bottom up vs invalidating PICS which are not bottom up. RE Picket Fence - policies have certain qualities - and have to remove these from the mission. * BBurr - no one is thinking of specs 1 and 4 should be in the mission - they are only notes for drafting. Current text provides a handle to address the non-bottom up concern of AG. * MMueller - the current mission has had consensus for the three rounds. We are not discussing if the mission is narrow and limited but rather talking about how best to do this and we cannot move away from this without risking consensus on everything. Agree with implication of BB analysis. GAC concern re advice Do GAC believe there should be no mission limitations? GAC advice against mission vs new TLDs would be an involuntary criterion. * MWeill - have to close. * MHutty - Agree with BB and Milton. One problem vs voluntary commitments. We need to work things we can get through and not worry about the things we will not. * JCancio - (GAC Switzerland): @staff Please include this on the notes as probably I won't have time to speak: jorge cancio (GAC Switzerland): Dear all: I feel for policy maker what the GAC and others are seeking is quite simple, which is an impact assessment of the proposed changes. This is current practice and should be acceptable without any doubt. In the GACs input a series of elements are identified which should be part of that impact assessment. Otherwise we have no clarity at all and no objective and neutral assessment at hand which would allow us to determine whether the proposed changes (which have been subject to last minute changes for a long time) outlaw certain important instruments which are available now, such as the PICs * MWeill - need to keep working on this complex issues. BB should take up the discussions. 6. AOB LS (3 min) * Friday CCWG meeting prior to ICANN 55 Marrakech is confirmed Adjourned.

1 0