From avri Fri Aug 1 09:04:46 2014 From: avri (Avri Doria) Date: Fri, 01 Aug 2014 08:04:46 +0200 Subject: [PC-NCSG] Draft Comments for Whois Proceeding In-Reply-To: <53DAA5CB.6080603@apc.org> References: <53D8E4D0.8080805@acm.org> <53D8EBB3.7060404@acm.org> <5762B7A6-B931-4E7A-AD19-7B2D92944023@egyptig.org> <53DA44C7.7090700@mail.utoronto.ca> <53DA5C0F.9050401@kathykleiman.com> <53DA8AAD.5080109@mail.utoronto.ca> <53DAA5CB.6080603@apc.org> Message-ID: <53DB2DFE.5010101@acm.org> Hi, Even though this version still contains the sentence about us being shocked that ICANN did nothing, which I think adds nothing and is shocking - how could we be shocked at ICANN behavior, i can accept this version. avri On 31-Jul-14 22:23, joy wrote: > Hi - I've inserted my para in the document again > maybe an online document would help next time :) > thanks everyone for the comments > I am happy to endorse this > Regards > > Joy > > On 1/08/2014 6:27 a.m., Stephanie Perrin wrote: >> Ok folks, I think we have a draft (5) which is now ready for final >> approval. I have taken Kathy's last draft, done a final edit >> (unfortunately I cannot restrain my editing, each time I go through >> the draft, as I find things I forgot to note the last time. So there >> are a few changes.) In deference to Avri's strong objection to the >> mention of multistakeholderism as being subservient to adherance to >> law, I did an edit of that sentence. >> It is unfortunate that Michele used the example of German law (as the >> lander each have their own laws and Commissioners, and I am quite >> unsure whose jurisdiction this issue would fall under) however I left >> it in. I also tried to clarify the paragraph where we discuss >> consultation on decisions regarding exemption. I hope it is now clear >> and reflects all members views on the matter. >> Rafik, I would recommend that when you digitally sign the clean copy >> you save it as NCSG comments on the WHOIS conflicts consultation, as >> the current title is messy (assuming we can now get concensus on >> moving forward and filing this tomorrow). >> Kind regards, >> Stephanie >> On 2014-07-31, 11:09, Kathy Kleiman wrote: >>> Hi Stephanie, >>> Tx for adding Avri's comments. I've reviewed all of the changes, and >>> also added one more to this most recent version. _Newest version >>> (NCSGEdits3) attached. _ >>> **Due tomorrow** >>> Best, >>> Kathy >>> : >>>> I also agreed with Avri and inserted a few of her changes, Kathy did >>>> not get those edits....we need to make sure we have a final copy >>>> that Rafik can sign, which reflects all the agreed changes. Do you >>>> want me to have another edit one last time, to make sure that Joy's >>>> comments (which were on an earlier draft) and Avri's are all in there? >>>> cheers stephanie >>>> On 2014-07-31, 9:22, Amr Elsadr wrote: >>>>> Hi all, >>>>> >>>>> On Jul 30, 2014, at 2:57 PM, Avri Doria wrote: >>>>> >>>>>> hi, >>>>>> >>>>>> Reviewed the document. >>>>>> >>>>>> Made a change so it could be a NCSG document. >>>>> Thanks. >>>>> >>>>>> There are parts I am uncomfortable with, some of which I deleted and >>>>>> some of which I left and still am uncomfortable with. >>>>>> >>>>>> I do not think we should ever dismiss the Multistakeholder model. >>>>>> I do >>>>>> not wish to find ourselves in the situation of being quoted for >>>>>> having >>>>>> suggested that there are times when the model should be >>>>>> superseded. That >>>>>> would be a gold mine for some. I deleted those references. >>>>> Fully agree. Although I don?t feel that was the intent, it could >>>>> certainly be perceived that way. No need to bring it up. >>>>> >>>>>> I am also uncomfortable with saying there are things that don't need >>>>>> public comment on. To just have to take the legal staff view on >>>>>> things >>>>>> is dangerous. What if they say the law does not require something >>>>>> when >>>>>> someone knows better. Better to have a null review. I have not, >>>>>> however, removed these as they were an entire section. I would >>>>>> like >>>>>> to see that section reworded or removed before approving the >>>>>> documents. >>>>> IMHO, I don?t see the need for a public comment period on every >>>>> time this policy might be used. If a new set of policies and >>>>> processes are adopted for handling WHOIS conflicts with privacy >>>>> laws, then they should be clear enough during implementation to not >>>>> require public comment, right? Isn?t this the case with all >>>>> policies? For instance, is there a public comment period every time >>>>> a new registrar signs a contract with ICANN? Or will there be a >>>>> public comment period when implementation of the ?thick? WHOIS >>>>> policy kicks in? >>>>> >>>>> Another thought is that a public comment period will also lengthen >>>>> the period during which a registrar will potentially be at risk for >>>>> non-compliance with local laws. Unless there is an important reason >>>>> why there should be a public comment for each of the resolution >>>>> scenarios, then I suggest we support Kathy?s recommendation to not >>>>> have any. >>>>> >>>>> Thanks. >>>>> >>>>> Amr >>>>> >>>>>> I also removed a bunch of weasel words like 'respectfully' >>>>>> >>>>>> avri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 30-Jul-14 14:28, Avri Doria wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Started reviewing them, actually Stephanie's comments. They are >>>>>>> written >>>>>>> from an NCUC perspective and need to be approved by them, not us. >>>>>>> >>>>>>> avri >>>>>>> >>>>>>> >>>>>>> On 30-Jul-14 11:36, Rafik Dammak wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> Kathy sent a draft comment to the whois conflict with local >>>>>>>> laws. we >>>>>>>> have a tight schedule and we should act quickly. >>>>>>>> we are responding during the reply period which means the last >>>>>>>> chance >>>>>>>> for us to do so. >>>>>>>> @Maria can you please follow-up with this request? >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Rafik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: *Kathy Kleiman* >>>>>>> > >>>>>>>> Date: 2014-07-30 2:44 GMT+09:00 >>>>>>>> Subject: Draft Comments for Whois Proceeding >>>>>>>> To: Rafik Dammak >>>>>>> >, NCSG-DISCUSS at listserv.syr.edu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> To Rafik, NCSG Executive Committee and NCSG Membership, >>>>>>>> >>>>>>>> There is an important, but very quiet comment proceeding that >>>>>>>> has been >>>>>>>> taking place this summer. It is the /Review of the ICANN >>>>>>>> Procedure for >>>>>>>> Handling WHOIS Conflicts with Privacy Law///at >>>>>>>> /https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stephanie put out a call for comments, and not seeing any, I >>>>>>>> drafted >>>>>>>> these. It has been dismayeding ever since ICANN adopted its >>>>>>>> Consensus >>>>>>>> Procedure for Handling WHOIS Conflicts with Privacy law -- >>>>>>>> because it >>>>>>>> basically requires that Registrars and Registries have to be >>>>>>>> sued or >>>>>>>> receive an official notice of violation before they can ask >>>>>>>> ICANN for a >>>>>>>> waiver of the Whois requirements. That always seemed very >>>>>>>> unfair- that >>>>>>>> you have to be exposed to allegation of illegal activity in >>>>>>>> order to >>>>>>>> protect yourself or your Registrants under your national data >>>>>>>> protection >>>>>>>> and privacy laws. >>>>>>>> >>>>>>>> In the more recent Data Retention Specification, of the 2013 >>>>>>>> RAA, ICANN >>>>>>>> Staff and Lawyers saw this problem and corrected it -- now >>>>>>>> Registrars >>>>>>>> can be much more pro-active in showing ICANN that a certain >>>>>>>> clause in >>>>>>>> their contract (e.g., extended data retention) is a clear >>>>>>>> violation of >>>>>>>> their national law (e.g., more limited data retention). >>>>>>>> >>>>>>>> So to this important comment proceeding, I drafted these >>>>>>>> comments for us >>>>>>>> to submit. As Reply Comments (during the Reply Period), we are >>>>>>>> asked to >>>>>>>> respond to other commenters. That's easy as the European >>>>>>>> Commission and >>>>>>>> Registrar Blacknight submitted useful comments. >>>>>>>> >>>>>>>> Rafik, can we edit, finalize and submit by the deadline on Friday? >>>>>>>> Comments below and attached. If you have edits, in the interest >>>>>>>> of time, >>>>>>>> kindly suggest alternate language. Tx!! >>>>>>>> >>>>>>>> Best, >>>>>>>> Kathy >>>>>>>> -------------------------------------------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> DRAFT NCSG Response to the Questions of the >>>>>>>> >>>>>>>> /Review of the ICANN Procedure for Handling WHOIS Conflicts with >>>>>>>> Privacy >>>>>>>> Law// >>>>>>>> https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Introduction* >>>>>>>> >>>>>>>> The Noncommercial Stakeholders Group represents noncommercial >>>>>>>> organizations in their work in the policy and proceedings of >>>>>>>> ICANN and >>>>>>>> the GNSO. We respectfully submit as an opening premise that >>>>>>>> every legal >>>>>>>> business has the right and obligation to operate within the >>>>>>>> bounds and >>>>>>>> limits of its national laws and regulations. No legal business >>>>>>>> establishes itself to violate the law; and to do so is an >>>>>>>> invitation to >>>>>>>> civil and criminal penalties. ICANN Registries and Registrars >>>>>>>> are no >>>>>>>> different ? they want and need to abide by their laws. >>>>>>>> >>>>>>>> Thus, it is timely for ICANN to raise the questions of this >>>>>>>> proceeding, >>>>>>>> /Review of the ICANN Procedure for Handling WHOIS Conflicts with >>>>>>>> Privacy >>>>>>>> Law/(albeit at a busy time for the Community and at the height of >>>>>>>> summer; we expect to see more interest in this time towards the >>>>>>>> Fall). >>>>>>>> We submit these comments in response to the issues raises and the >>>>>>>> questions asked. >>>>>>>> >>>>>>>> *Background* >>>>>>>> >>>>>>>> The /ICANN Procedure for Handling Whois Conflicts with Privacy >>>>>>>> Law /was >>>>>>>> adopted in 2006 after years of debate on Whois issues. This >>>>>>>> Consensus >>>>>>>> Procedure was the first step of recognition that data protection >>>>>>>> laws >>>>>>>> and privacy law DO apply to the personal and sensitive data being >>>>>>>> collected by Registries and Registrars for the Whois database. >>>>>>>> >>>>>>>> But for those of us in the Noncommercial Users Constituency (now >>>>>>>> part of >>>>>>>> the Noncommercial Stakeholders Group/NCSG) who helped debate, >>>>>>>> draft and >>>>>>>> adopt this Consensus Procedure in the mid-2000s, we were always >>>>>>>> shocked >>>>>>>> that the ICANN Community did not do more. At the time, multiple >>>>>>>> Whois >>>>>>>> Task Forces were at work with multiple proposals which include >>>>>>>> important >>>>>>>> and pro-active suggestions to allow Registrars and Registries to >>>>>>>> come >>>>>>>> into compliance with their national data protection and privacy >>>>>>>> laws. >>>>>>>> >>>>>>>> At the time, we never expected this Consensus Procedure to be an >>>>>>>> end >>>>>>>> itself ? but the first step of many steps. It was an ?end? for >>>>>>>> too long, >>>>>>>> so we are glad the discussion is reopened and once again we seek to >>>>>>>> allow Registrars and Registries to be in full compliance with their >>>>>>>> national data protection and privacy laws ? from the moment they >>>>>>>> enter >>>>>>>> into their contracts with ICANN. >>>>>>>> >>>>>>>> *II. Data Protection and Privacy Laws ? A Quick Overview of the >>>>>>>> Principles that Protect the Personal and Sensitive Data of >>>>>>>> Individuals >>>>>>>> and Organizations/Small Businesses * >>>>>>>> >>>>>>>> ** >>>>>>>> >>>>>>>> /*[Stephanie, Tamir or Others with Expertise in Canadian and >>>>>>>> European >>>>>>>> Data Protection Laws may choose to add something here]. */ >>>>>>>> >>>>>>>> III/*. */Questions asked of the Community in this Proceeding >>>>>>>> >>>>>>>> The ICANN Review Paper raised a number of excellent questions. In >>>>>>>> keeping with the requirements of a Reply Period, these NCSG >>>>>>>> comments >>>>>>>> will address both our comments and those comments we particularly >>>>>>>> support in this proceeding. >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> Is it impractical for ICANN to require that a contracted >>>>>>>> party >>>>>>>> already has litigation or a government proceeding initiated >>>>>>>> against it prior to being able to invoke the Whois >>>>>>>> Procedure? >>>>>>>> >>>>>>>> 1.1 Response: Yes, it is completely impractical (and >>>>>>>> ill-advised) to >>>>>>>> force a company to violate a national law as a condition of >>>>>>>> complying >>>>>>>> with that national law. Every lawyer advises businesses to >>>>>>>> comply with >>>>>>>> the laws and regulations of their field. To do otherwise is to face >>>>>>>> fines, penalties, loss of the business, even jail for officers and >>>>>>>> directors. Legal business strives to be law-abiding; no officer or >>>>>>>> director wants to go to jail for her company's violations. It is >>>>>>>> the >>>>>>>> essence of an attorney's advice to his/her clients to fully >>>>>>>> comply with >>>>>>>> the laws and operate clearly within the clear boundaries and >>>>>>>> limits of >>>>>>>> laws and regulations, both national, by province or state and >>>>>>>> local. >>>>>>>> >>>>>>>> In these Reply Comments, we support and encourage ICANN to adopt >>>>>>>> policies consistent with the initial comments submitted by the >>>>>>>> European >>>>>>>> Commission: >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> that the Whois Procedure be changed from requiring specific >>>>>>>> prosecutorial action instead to allowing ?demonstrating >>>>>>>> evidence >>>>>>>> of a potential conflict widely and e.g. accepting >>>>>>>> information on >>>>>>>> the legislation imposing requirements that the contractual >>>>>>>> requirements would breach as sufficient evidence.? (European >>>>>>>> Commission comments) >>>>>>>> >>>>>>>> We also agree with Blacknight: >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> ?It's completely illogical for ICANN to require that a >>>>>>>> contracting party already has litigation before they can >>>>>>>> use a >>>>>>>> process. We would have loved to use a procedure or >>>>>>>> process to >>>>>>>> get exemptions, but expecting us to already be litigating >>>>>>>> before >>>>>>>> we can do so is, for lack of a better word, nuts.? >>>>>>>> (Blacknight >>>>>>>> comments in this proceeding). >>>>>>>> >>>>>>>> >>>>>>>> 1.1a How can the triggering event be meaningfully defined? >>>>>>>> >>>>>>>> 1.1 a Response: This is an important question. Rephrased, we >>>>>>>> might ask >>>>>>>> together ? what must a Registry or Registrar show ICANN in >>>>>>>> support of >>>>>>>> its claim that certain provisions involving Whois data violate >>>>>>>> provisions of national data protection and privacy laws? >>>>>>>> >>>>>>>> NCSG respectfully submits that there are at least four ?triggering >>>>>>>> events? that ICANN should recognize: >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> Evidence from a national Data Protection Commissioner or >>>>>>>> his/her >>>>>>>> office (or from a internationally recognized body of >>>>>>>> national >>>>>>>> Data Protection Commissioners in a certain region of the >>>>>>>> world, >>>>>>>> including the Article 29 Working Party that analyzes the >>>>>>>> national data protection and privacy laws) that ICANN's >>>>>>>> contractual obligations for Registry and/or Registrar >>>>>>>> contracts >>>>>>>> violate the data protection laws of their country or >>>>>>>> their group >>>>>>>> of countries; >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> Evidence of legal and/or jurisdictional conflict arising >>>>>>>> from >>>>>>>> analysis performed by ICANN's legal department or by >>>>>>>> national >>>>>>>> legal experts hired by ICANN to evaluate the Whois >>>>>>>> requirements >>>>>>>> of the ICANN contracts for compliance and conflicts with >>>>>>>> national data protection laws and cross-border transfer >>>>>>>> limits) >>>>>>>> (similar to the process we understand was undertaken for the >>>>>>>> data retention issue); >>>>>>>> >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> Receipt of a written legal opinion from a nationally >>>>>>>> recognized >>>>>>>> law firm in the applicable jurisdiction that states that the >>>>>>>> collection, retention and/or transfer of certain Whois data >>>>>>>> elements as required by Registrar or Registry Agreements is >>>>>>>> ?reasonably likely to violate the applicable law? of the >>>>>>>> Registry or Registrar (per the process allowed in RAA Data >>>>>>>> Retention Specification); or >>>>>>>> >>>>>>>> >>>>>>>> o >>>>>>>> >>>>>>>> An official opinion of any other governmental body of >>>>>>>> competent >>>>>>>> jurisdiction providing that compliance with the data >>>>>>>> protection >>>>>>>> requirements of the Registry/Registrar contracts violates >>>>>>>> applicable national law (although such pro-active >>>>>>>> opinions may >>>>>>>> not be the practice of the Data Protection Commissioner's >>>>>>>> office). >>>>>>>> >>>>>>>> The above list draws from the comments of the European >>>>>>>> Commission, Data >>>>>>>> Retention Specification of the 2013 Registrar Accreditation >>>>>>>> Agreement, >>>>>>>> and sound compliance and business practices for the ICANN General >>>>>>>> Counsel's office. >>>>>>>> >>>>>>>> We further agree with Blacknight that the requirements for >>>>>>>> triggering >>>>>>>> any review and consideration by ICANN be: simple and >>>>>>>> straightforward, >>>>>>>> quick and easy to access. >>>>>>>> >>>>>>>> >>>>>>>> 1.3 Are there any components of the triggering >>>>>>>> event/notification >>>>>>>> portion of the RAA's Data Retention waiver process that should be >>>>>>>> considered as optional for incorporation into a modified Whois >>>>>>>> Procedure? >>>>>>>> >>>>>>>> >>>>>>>> 1.3 Response: Absolutely, the full list in 1.1a above, together >>>>>>>> with >>>>>>>> other constructive contributions in the Comments and Reply >>>>>>>> Comments of >>>>>>>> this proceeding, should be strongly considered for incorporation >>>>>>>> into a >>>>>>>> modified Whois Procedure, or simply written into the contracts >>>>>>>> of the >>>>>>>> Registries and Registrars contractual language, or a new Annex or >>>>>>>> Specification. >>>>>>>> >>>>>>>> We respectfully submit that the obligation of Registries and >>>>>>>> Registrars >>>>>>>> to comply with their national laws is not a matter of >>>>>>>> multistakeholder >>>>>>>> decision making, but a matter of law and compliance. In this >>>>>>>> case, we >>>>>>>> wholeheartedly embrace the concept of building a process >>>>>>>> together that >>>>>>>> will allow exceptions for data protection and privacy laws to be >>>>>>>> adopted >>>>>>>> quickly and easily. >>>>>>>> >>>>>>>> >>>>>>>> 1.4 Should parties be permitted to invoke the Whois Procedure >>>>>>>> before >>>>>>>> contracting with ICANN as a registrar or registry? >>>>>>>> >>>>>>>> >>>>>>>> 1.4 Response: Of course, Registries and Registrars should be >>>>>>>> allowed to >>>>>>>> invoke the Whois Procedure, or other appropriate annexes and >>>>>>>> specifications that may be added into Registry and Registrar >>>>>>>> contracts >>>>>>>> with ICANN. As discussed above, the right of a legal company to >>>>>>>> enter >>>>>>>> into a legal contracts is the most basic of expectations under law. >>>>>>>> >>>>>>>> >>>>>>>> 2.1 Are there other relevant parties who should be included >>>>>>>> in this >>>>>>>> step? >>>>>>>> >>>>>>>> >>>>>>>> 2.1 Response: We agree with the EC that ICANN should be working as >>>>>>>> closely with National Data Protection Authorities as they will >>>>>>>> allow. In >>>>>>>> light of the overflow of work into these national commissions, >>>>>>>> and the >>>>>>>> availability of national experts at law firms, ICANN should also >>>>>>>> turn to >>>>>>>> the advice of private experts, such as well-respected law firms who >>>>>>>> specialize in national data protection laws. The law firm's >>>>>>>> opinions on >>>>>>>> these matters would help to guide ICANN's knowledge and >>>>>>>> evaluation of >>>>>>>> this important issue. >>>>>>>> >>>>>>>> >>>>>>>> 3.1 How is an agreement reached and published? >>>>>>>> >>>>>>>> 3.1 Response. As discussed above, compliance with national law >>>>>>>> may not >>>>>>>> be the best matter for negotiation within a multistakeholder >>>>>>>> process. It >>>>>>>> really should not be a chose for others to make whether you >>>>>>>> comply with >>>>>>>> your national data protection and privacy laws. That said, the >>>>>>>> process >>>>>>>> of refining the Consensus Procedure, and adopting new policies and >>>>>>>> procedures, or simply putting new contract provisions, annexes or >>>>>>>> specifications into the Registry and Registrar contracts SHOULD be >>>>>>>> subject to community discussion, notification and review. But >>>>>>>> once the >>>>>>>> new process is adopted, we think the new changes, variations, >>>>>>>> modifications or exceptions of Individual Registries and >>>>>>>> Registrars need >>>>>>>> go through a public review and process. The results, however, >>>>>>>> Should be >>>>>>>> published for Community notification and review. >>>>>>>> >>>>>>>> >>>>>>>> We note that in conducting the discussion with the Community on the >>>>>>>> overall or general procedure, policy or contractual changes, ICANN >>>>>>>> should be assertive in its outreach to the Data Protection >>>>>>>> Commissioners. Individual and through their organizations, they >>>>>>>> have >>>>>>>> offered to help ICANN evaluate this issue numerous times. The Whois >>>>>>>> Review Team noted the inability of many external bodies to >>>>>>>> monitor ICANN >>>>>>>> regularly, but the need for outreach to them by ICANN staff >>>>>>>> nonetheless: >>>>>>>> >>>>>>>> >>>>>>>> *Recommendation 3: Outreach* >>>>>>>> >>>>>>>> *ICANN should ensure that WHOIS policy issues are accompanied by >>>>>>>> cross-community* >>>>>>>> >>>>>>>> *outreach, including outreach to the communities outside of >>>>>>>> ICANN with a >>>>>>>> specific* >>>>>>>> >>>>>>>> *interest in the issues, and an ongoing program for consumer >>>>>>>> awareness.* >>>>>>>> >>>>>>>> This is a critical policy item for such outreach and input. >>>>>>>> >>>>>>>> >>>>>>>> 3.2 If there is an agreed outcome among the relevant parties, >>>>>>>> should >>>>>>>> the Board be involved in this procedure? >>>>>>>> >>>>>>>> >>>>>>>> 3.2 Response: Clearly, the changing of the procedure, or the >>>>>>>> adoption of >>>>>>>> a new policy or new contractual language for Registries and >>>>>>>> Registrars, >>>>>>>> Board oversight and review should be involved. But once the new >>>>>>>> procedure, policy or contractual language is in place, then >>>>>>>> subsequent >>>>>>>> individual changes, variations, modifications or exceptions >>>>>>>> should be >>>>>>>> handled through the process and ICANN Staff ? as the Data Retention >>>>>>>> Process is handled today. >>>>>>>> >>>>>>>> >>>>>>>> 4.1 Would it be fruitful to incorporate public comment in >>>>>>>> each of >>>>>>>> the resolution scenarios? >>>>>>>> >>>>>>>> 4.1 Response: We think this question means whether there should be >>>>>>>> public input on each and every exception? We respectfully submit >>>>>>>> that >>>>>>>> the answer is No. Once the new policy, procedure or contractual >>>>>>>> language >>>>>>>> is adopted, then the process should kick in and the >>>>>>>> Registrar/Registry >>>>>>>> should be allowed to apply for the waiver, modification or revision >>>>>>>> consistent with its data protection and privacy laws. Of course, >>>>>>>> once >>>>>>>> the waiver or modification is granted, the decision should be >>>>>>>> matter of >>>>>>>> public record so that other Registries and Registrars in the >>>>>>>> jurisdiction know and so that the ICANN Community as a whole can >>>>>>>> monitor >>>>>>>> this process' implementation and compliance. >>>>>>>> >>>>>>>> Step Five: Public notice >>>>>>>> >>>>>>>> >>>>>>>> 5.2 Is the exemption or modification termed to the length of the >>>>>>>> agreement? Or is it indefinite as long as the contracted party is >>>>>>>> located in the jurisdiction in question, or so long as the >>>>>>>> applicable >>>>>>>> law is in force. >>>>>>>> >>>>>>>> 5.2 Response: We agree with the European Commission in its >>>>>>>> response, >>>>>>>> ?/By logic the exemption or modification shall be in place as >>>>>>>> long as >>>>>>>> the party is subject to the jurisdiction in conflict with ICANN >>>>>>>> rules. >>>>>>>> If the applicable law was to change, or the contacted party >>>>>>>> moved to a >>>>>>>> different jurisdiction, the conditions should be reviewed to >>>>>>>> assess if >>>>>>>> the exemption is still justified.? But provided it is the same >>>>>>>> parties, >>>>>>>> operating under the same laws, the modification or change should >>>>>>>> continue through the duration of the relationship between the >>>>>>>> Registry/Registrar and ICANN. / >>>>>>>> >>>>>>>> >>>>>>>> 5.3 Should an exemption or modification based on the same >>>>>>>> laws and >>>>>>>> facts then be granted to other affected contracted parties in >>>>>>>> the same >>>>>>>> jurisdiction without invoking the Whois Procedure >>>>>>>> >>>>>>>> 5.3 Response. The European Commission in its comments wrote, and we >>>>>>>> strongly agree: /?the same exception should apply to others in >>>>>>>> the same >>>>>>>> jurisdiction who can demonstrate that they are in the same >>>>>>>> situation.? >>>>>>>> /Further, Blacknight wrote and we support: /?if ANY registrar in >>>>>>>> Germany, for example, is granted a waiver based on German law, >>>>>>>> than ALL >>>>>>>> registrars based in Germany should receive the same treatment.? >>>>>>>> /Once a >>>>>>>> national data protection or privacy law is interpreted as >>>>>>>> requiring and >>>>>>>> exemption or modification, it should be available to all >>>>>>>> Registries/Registrars in that country. >>>>>>>> >>>>>>>> Further, we recommend that ICANN should be required to notify >>>>>>>> each gTLD >>>>>>>> Registry and Registrar in the same jurisdiction as that of the >>>>>>>> decision >>>>>>>> so they will have notice of the change. >>>>>>>> >>>>>>>> We thank ICANN staff for holding this comment period. >>>>>>>> >>>>>>>> Respectfully submitted, >>>>>>>> >>>>>>>> NCSG >>>>>>>> >>>>>>>> >>>>>>>> DRAFT >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PC-NCSG mailing list >>>>>>>> PC-NCSG at ipjustice.org >>>>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> PC-NCSG mailing list >>>>>>> PC-NCSG at ipjustice.org >>>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>>>> >>>>>>> >>>>>> >>>>> Proceduresp+ad.doc>_______________________________________________ >>>>>> PC-NCSG mailing list >>>>>> PC-NCSG at ipjustice.org >>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>> >>>>> _______________________________________________ >>>>> PC-NCSG mailing list >>>>> PC-NCSG at ipjustice.org >>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >> >> >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > From stephanie.perrin Fri Aug 1 13:04:01 2014 From: stephanie.perrin (Stephanie Perrin) Date: Fri, 1 Aug 2014 06:04:01 -0400 Subject: [PC-NCSG] [NCSG-Discuss] [urgent] Draft Comments for Whois Proceeding In-Reply-To: <53DA7A94.2060606@yorku.ca> References: <53D8E4D0.8080805@acm.org> <53D8EBB3.7060404@acm.org> <5762B7A6-B931-4E7A-AD19-7B2D92944023@egyptig.org> <53DA44C7.7090700@mail.utoronto.ca> <53DA5C0F.9050401@kathykleiman.com> <53DA6724.20108@mail.utoronto.ca> <53DA7A94.2060606@yorku.ca> Message-ID: <53DB6611.6090606@mail.utoronto.ca> Thanks, Sam! Responses to your comments: 1) I have discussed this a bit with Avri and I am reluctant to drop the Snowden reference, even if it is a wee bit inflammatory....this is partly because I am tired of talking in general terms about public policy, they will simply interpret that as compliance with law enforcement demands, not privacy expectations of consumers. 2) agreed, I am tempted to say that in the comment but resisting 3) re the typos, I will have to go back, check the quotes, and square bracket/sic them. thanks! cheers stephanie On 2014-07-31, 13:19, Sam Lanfranco wrote: > It is late in the time left for revising this document so I will just > offer three short comments without going in and attempting to > wordsmith inside the document. Food for though! > > #1: Page 1: As part of the opening logic to the submission the text > as written is: > > /In the matter of protection of personal and confidential information, > which is a very newsworthy issue in the 21st century, privacy > practices are a matter of consumer trust, and therefore high risk for > those operating an Internet business. Even if customers have > obediently complied with demands for excessive collection and > disclosure of personal information up to this point, in the current > news furor over Snowden and the cooperation of business with national > governments engaged in surveillance, this could change with the next > news story. The Internet facilitates successful privacy campaigns./ > > I would suggest that the submission focus in immediately on ICANN > practice and evolving policy on the protection of personal and > confidential information, and not so much Snowden and news stories. > > [Possible revision] > > /In the matter of protection of personal and confidential information > on the Internet social norms and public policy are evolving and ICANN > should be in the forefront of helping define workable practice, as > well as bringing its contract language in line with public policy. It > is bad ICANN business practice to put registrars at odds with national > privacy policy. It also jeopardizes registrars' consumer trust and > puts at risk the business of those operating an Internet business. / > > #2: [Comment] There is a saying about the Catholic Church, to the > effect that dealing with social norms it always arrives a little late > and out of breath. ICANN is acting in a similar way. ICANN could both > handle this in contract language, and help evolve best and workable > practices around the protection of personal and confidential > information by (a) contract language that is consistent with national > policy, and (b) showing some leadership in what would be good and > workable policy here. ICANN is neither a King nor a Church bestowing > favors on registries and registrars. It is a business entering into > contractual obligations with its direct customers. > > #3: [*Typo*] I don't know if the typo is in the Blacknight quote or > not, but 5.3 should read ...., then [not than] ALL registrars based in > Germany..." > > 5.3 Response. The European Commission in its comments wrote, and we > strongly agree: "the same exception should apply to others in the same > jurisdiction who can demonstrate that they are in the same situation." > Further, Blacknight wrote and we support: "if ANY registrar in > Germany, for example, is granted a waiver based on German law, *then* > ALL registrars based in Germany should receive the same treatment." > Once a national data protection or privacy law is interpreted as > requiring and exemption or modification, it should be available to all > Registries/Registrars in that country. > > Sam L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephanie.perrin Fri Aug 1 13:24:38 2014 From: stephanie.perrin (Stephanie Perrin) Date: Fri, 1 Aug 2014 06:24:38 -0400 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> Message-ID: <53DB6AE6.8040008@mail.utoronto.ca> Thanks for sending, I am having trouble with attachments but I got it. I think I have made all the corrections now, here is the amended version 6, I believe you can post it. cheers Stephanie On 2014-08-01, 6:11, Rafik Dammak wrote: > > Hi Stephanie, > > I think joy included her language in the attached document, can you > please merge that with the latest draft you circulated? > Lesson learned: using a shared online document and avoid the word > document versioning nightmare. > > Best, > > Rafik > > ---------- Forwarded message ---------- > From: "joy" > > Date: Jul 31, 2014 3:05 AM > Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding > To: > > Cc: > > Hi - thanks everyone for the effort on this > I have also added some information on the recent report of the UN High > Commissioner for Human Rights on the right to privacy in the digital age > - which includes aspects relevant for companies - plus one or two other > minor comments > Hope you get these in time! > Joy > > On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: > > Hi All, > > Attached is the revised version of the comments. It has the changes of > > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's > > signature and submission on behalf of the NCSG (feel free to add an > > electronic signature, Rafik!). (Track changes version showing edits > > attached) > > > > If you could please use _this version _of the revised comments for > > review and submission, that would be great. > > Best, > > Kathy > > > > > > > ----------------------------------------------------------------------------------------------------------------------------------------------- > > > > NCSG Response to the Questions of the > > > > /Review of the ICANN Procedure for Handling WHOIS Conflicts with > > Privacy Law / > > > > > https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// > > > > > > ** > > > > The Noncommercial Stakeholders Group represents noncommercial > > organizations and individual noncommercial users in their work in the > > policy and proceedings of ICANN and the GNSO. We respectfully submit > > as an opening premise that every legal business has the right and > > obligation to operate within the bounds and limits of its national > > laws and regulations. No legal business establishes itself to violate > > the law; and to do so is an invitation to civil and criminal > > penalties, in addition to reputational damage and a loss of the trust > > of their customers and business partner. ICANN Registries and > > Registrars are no different ? they want and need to abide by their laws. > > > > To that end, Registries and Registrars strive to comply with their > > national and local laws.They strive affirmatively and proactively to > > follow the laws and regulations under which they operate as legal > > entities. To do otherwise is to violate the purpose of a legal regime, > > to threaten the well being of the company, and to expose Directors, > > Officers and Employees to fines, jail, or civil litigation. In the > > matter of protection of personal and confidential information, which > > is a very newsworthy issue in the 21^st century, privacy practices are > > a matter of consumer trust, and therefore high risk for those > > operating an Internet business.Even if customers have obediently > > complied with demands for excessive collection and disclosure of > > personal information up to this point, in the current news furor over > > Snowden and the cooperation of business with national governments > > engaged in surveillance, this could change with the next news > > story.The Internet facilitates successful privacy campaigns. > > > > Thus, it is wise and timely for ICANN to raise the questions of this > > proceeding, /Review of the ICANN Procedure for Handling WHOIS > > Conflicts with Privacy Law/ (albeit at a busy time for the Community > > and at the height of summer; we expect to see more interest in this > > time towards the Fall and recommend that ICANN not construe the small > > number of comments received to date as a reflection of lack of > > interest). We submit these comments in response to the issues raises > > and the questions asked. > > > > *Background* > > > > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law > > /was adopted in 2006 after years of debate on Whois issues. This > > Consensus Procedure was the first step of recognition that data > > protection laws and privacy law DO apply to the personal and sensitive > > data being collected by Registries and Registrars for the Whois > database. > > > > But for those of us in the Noncommercial Users Constituency (now part > > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft > > and adopt this Consensus Procedure in the mid-2000s, we were always > > shocked that the ICANN Community did not do more. At the time, several > > Whois Task Forces were at work with multiple proposals which include > > important and pro-active suggestions to allow Registrars and > > Registries to come into compliance with their national and local data > > protection and privacy laws. > > > > At the time, we never expected this Consensus Procedure to be an end > > itself ? but the first of many steps. We are glad the discussion is > > now reopened and we support empowering Registrars and Registries to be > > in full compliance with their national and local data protection, > > consumer protection and privacy laws ? from the moment they enter into > > their contracts with ICANN. > > > > We note there have been a number of recent decisions in higher courts > > in various jurisdictions which impact the constitutional rights of > > citizens to be free from warrantless disclosure and retention of their > > personal information for law enforcement purposes.This reflects the > > time it takes for data protection issues to wend their way to the high > > courts for a ruling.We would urge ICANN, who otherwise sit on the > > cutting edge of Internet technical issues, to reflect on their role as > > a key global player in Internet governance.Do we lead or do we wait > > until we are dragged into Court, to realize our responsibilities to > > protect the fundamental rights of the citizens who depend on the > > Internet to participate in modern society?// > > > > II. Data Protection and Privacy Laws ? A Quick Overview of the > > Principles that Protect the Personal and Sensitive Data of Individuals > > and Organizations/Small Businesses > > > > It is important to stress that while the discourse about data > > protection requirements at ICANN has tended to focus on the European > > Union and its Data Commissioners, as represented in the Article 29 > > Working Party on Data Protection, there are a great many countries > > which have data protection law in place, including Canada, Mexico, > > much of South America, Korea, Japan, Australia, New Zealand, > > Singapore, South Africa, and many others.It is therefore quite > > puzzling that ICANN does not assemble a working group to study the > > matter and develop a harmonized approach to the issue, rather than > > take this rather odd approach of forcing registrars and registries to > > break national and local law. > > > > It is also important to note that there are many levels of data > > protection law, from local municipal law to state and national > > law.There is also sectoral law which applies to certain sectors.It > > would be a reasonable approach to develop a policy that reflects > > harmonized best practice, and abide by the policy rather than engage > > in this adversarial approach to local law.Data protection law is > > overwhelmingly complaints based, so it is inherently difficult for > > registrars and registries to get a ruling from data protection > > commissioners absent a complaint and a set of facts. > > > > In this regard, we also find it puzzling that despite the fact that > > the Article 29 Working Party wrote to ICANN senior management to > > indicate that they have reviewed the matter and reached an opinion > > that the practices involving WHOIS do indeed violate EU law, ICANN has > > not taken that message and developed a policy that guides their data > > protection practices, starting with a clear statement of limited > > purpose for the collection, use, and disclosure of personal information. > > > > The NCSG held a privacy meeting at the London ICANN 50 meeting, which > > was quite well attended.While we did not specifically address or > > attempt to brainstorm this particular problem, we feel it is safe to > > summarize the following points: > > > > ?There is considerable interest, in civil society, in the protection > > of personal information at ICANN. > > > > ?Policies and procedures such as were developed for the 2013 RAA are > > very puzzling to those who are engaged in government and business in > > the privacy field.This is not 1995, when the EU Directive on data > > protection was passed and was still controversial.ICANN needs to catch > > up with global business practice, preferably by developing binding > > corporate rules which would take a harmonized approach to the > > differing local laws. It is not appropriate for all data protection to > > fall away in jurisdictions where there is not yet a data protection > > law that applies to the provision of internet services, including > > domain name registration. > > > > ?NCSG is ramping up a team of volunteers to provide more detailed > > expertise and input on a number of privacy and free speech > > issues.While civil society is inherently stretched and short of > > resources, this is an issue that they care deeply about, and our > > outreach has begun to bear fruit in engaging others who are outside > > the immediate sphere of ICANN membership.This is important as they are > > part of the constituency we seek to represent. > > > > ICANN spends considerable time on technical parameters, data accuracy, > > and retention.More time needs to be spent on data protection policy.In > > this respect, more expertise would be required as there is very little > > evidence of privacy expertise in the ICANN community. > > > > III*/./*Questions asked of the Community in this Proceeding > > > > The ICANN Review Paper raised a number of excellent questions. In > > keeping with the requirements of a Reply Period, these NCSG comments > > will address both our comments and those comments we particularly > > support in this proceeding. > > > > However we would first like to note that the paper appears to start > > from the position that the procedures involved in this waiver process > > simply need to be tweaked.Operating under the first principle that all > > business must comply with local law, there is a need for ICANN to > > embrace data protection law as a well recognized branch of law which > > codifies well recognized business best practices with respect to the > > confidentiality of customer data.We respectfully submit that, if ICANN > > had a professional privacy officer, it is highly unlikely that he/she > > would recommend to senior management that the current approach be > > entertained in 2014. > > > > 1.1Is it impractical for ICANN to require that a contracted party > > already haslitigation or a government proceeding initiated against it > > prior to being able to invoke the Whois Procedure? > > > > 1.1 Response: Yes, it is completely impractical (and ill-advised) to > > force a company to violate a national law as a condition of complying > > with their contract. Every lawyer advises businesses to comply with > > the laws and regulations of their field. To do otherwise is to face > > fines, penalties, loss of the business, even jail for officers and > > directors. Legal business strives to be law-abiding; no officer or > > director wants to go to jail for her company's violations. It is the > > essence of an attorney's advice to his/her clients to fully comply > > with the laws and operate clearly within the clear boundaries and > > limits of laws and regulations, both national, by province or state > > and local. > > > > In these Reply Comments, we support and encourage ICANN to adopt > > policies consistent with the initial comments submitted by the > > European Commission: > > > > -that the Whois Procedure be changed from requiring specific > > prosecutorial action instead to allowing ?demonstrating evidence of a > > potential conflict widely and e.g. accepting information on the > > legislation imposing requirements that the contractual requirements > > would breach as sufficient evidence.? (European Commission comments) > > > > We also agree with Blacknight: > > > > -?It's completely illogical for ICANN to require that a contracting > > party already has litigation before they can use a process. We would > > have loved to use a procedure or process to get exemptions, but > > expecting us to already be litigating before we can do so is, for lack > > of a better word, nuts.? (Blacknight comments in this proceeding). > > > > - > > > > 1.1a How can the triggering event be meaningfully defined? > > > > This is an important question. Rephrased, we might ask together ?what > > must a Registry or Registrar show ICANN in support of its claim that > > certain provisions involving Whois data violate provisions of national > > data protection and privacy laws? > > > > NCSG respectfully submits that there are at least four ?triggering > > events? that ICANN should recognize: > > > > -Evidence from a national Data Protection Commissioner or his/her > > office (or from a internationally recognized body of national Data > > Protection Commissioners in a certain region of the world, including > > the Article 29 Working Party that analyzes the national data > > protection and privacy laws) that ICANN's contractual obligations for > > Registry and/or Registrar contracts violate the data protection laws > > of their country or their group of countries; > > > > -Evidence of legal and/or jurisdictional conflict arising from > > analysis performed by ICANN's legal department or by national legal > > experts hired by ICANN to evaluate the Whois requirements of the ICANN > > contracts for compliance and conflicts with national data protection > > laws and cross-border transfer limits) (similar to the process we > > understand was undertaken for the data retention issue); > > > > -Receipt of a written legal opinion from a nationally recognized law > > firm or qualified legal practitioner in the applicable jurisdiction > > that states that the collection, retention and/or transfer of certain > > Whois data elements as required by Registrar or Registry Agreements is > > ?reasonably likely to violate the applicable law? of the Registry or > > Registrar (per the process allowed in RAA Data Retention > > Specification); or > > > > -An official opinion of any other governmental body of competent > > jurisdiction providing that compliance with the data protection > > requirements of the Registry/Registrar contracts violates applicable > > national law (although such pro-active opinions may not be the > > practice of the Data Protection Commissioner's office). > > > > The above list draws from the comments of the European Commission, > > Data Retention Specification of the 2013Registrar Accreditation > > Agreement, and sound compliance and business practices for the ICANN > > General Counsel's office. > > > > We further agree with Blacknight that the requirements for triggering > > any review and consideration by ICANN be: simple and straightforward, > > quick and easy to access. > > > > 1.3Are there any components of the triggering event/notification > > portion of the RAA's Data Retention waiver process that should be > > considered as optional for incorporation into a modified Whois > Procedure? > > > > 1.3 Response:Absolutely, the full list in 1.1a above, together with > > other constructive contributions in the Comments and Reply Comments of > > this proceeding, should be strongly considered for incorporation into > > a modified Whois Procedure, or simply written into the contracts of > > the Registries and Registrars contractual language, or a new Annex or > > Specification. > > > > We respectfully submit that the obligation of Registries and > > Registrars to comply with their national laws is not a matter of > > multistakeholder decision making, but a matter of law and compliance. > > In this case, we wholeheartedly embrace the concept of building a > > process together that will allow exceptions for data protection and > > privacy laws to be adopted quickly and easily. > > > > 1.4Should parties be permitted to invoke the Whois Procedure before > > contracting with ICANN as a registrar or registry? > > > > 1.4 Response: Of course, Registries and Registrars should be allowed > > to invoke the Whois Procedure, or other appropriate annexes and > > specifications that may be added into Registry and Registrar contracts > > with ICANN. As discussed above, the right of a legal company to enter > > into a legal contracts is the most basic of expectations under law. > > > > 2.1Are there other relevant parties who should be included in this step? > > > > 2.1 Response: We agree with the EC that ICANN should be working as > > closely with National Data Protection Authorities as they will allow. > > In light of the overflow of work into these national commissions, and > > the availability of national experts at law firms, ICANN should also > > turn to the advice of private experts,such as well-respected law firms > > who specialize in national data protection laws. The law firm's > > opinions on these matters would help to guide ICANN's knowledge and > > evaluation of this important issue. > > > > 3.1How is an agreement reached and published? > > > > 3.1 Response. As discussed above, compliance with national law may not > > be the best matter for negotiation within a multistakeholder process. > > It really should not be a chose for others to make whether you comply > > with your national data protection and privacy laws. That said, the > > process of refining the Consensus Procedure, and adopting new policies > > and procedures, or simply putting new contract provisions, annexes or > > specifications into the Registry and Registrar contracts SHOULD be > > subject to community discussion, notification and review.But once the > > new process is adopted, we think the new changes, variations, > > modifications or exceptions of Individual Registries and Registrars > > need go through a public review and process. The results, however, > > Should be published for Community notification and review. > > > > We note that in conducting the discussion with the Community on the > > overall or general procedure, policy or contractual changes, ICANN > > should be assertive in its outreach to the Data Protection > > Commissioners. Individual and through their organizations, they have > > offered to help ICANN evaluate this issue numerous times. The Whois > > Review Team noted the inability of many external bodies to monitor > > ICANN regularly, but the need for outreach to them by ICANN staff > > nonetheless: > > > > *Recommendation 3:Outreach* > > > > *ICANN should ensure that WHOIS policy issues are accompanied by > > cross-community outreach, including outreach to the communities > > outside of ICANN with a specific interest in the issues, and an > > ongoing program for consumer awareness. (Whois Review Team Final > Report)* > > > > This is a critical policy item for such outreach and input. > > > > 3.2If there is an agreed outcome among the relevant parties, should > > the Board be involved in this procedure? > > > > 3.2 Response: Clearly, the changing of the procedure, or the adoption > > of a new policy or new contractual language for Registries and > > Registrars, Board oversight and review should be involved. But once > > the new procedure, policy or contractual language is in place, then > > subsequent individual changes, variations, modifications or exceptions > > should be handled through the process and ICANN Staff ? as the Data > > Retention Process is handled today. > > > > 4.1Would it be fruitful to incorporate public comment in each of the > > resolution scenarios. > > > > 4.1 Response: We think this question means whether there should be > > public input on each and every exception?We respectfully submit that > > the answer is No. Once the new policy, procedure or contractual > > language is adopted, then the process should kick in and the > > Registrar/Registry should be allowed to apply for the waiver, > > modification or revision consistent with its data protection and > > privacy laws.Of course, once the waiver or modification is granted, > > the decision should be matter of public record so that other > > Registries and Registrars in the jurisdiction know and so that the > > ICANN Community as a whole can monitor this process' implementation > > and compliance. > > > > Step Five: Public notice > > > > 5.2Is the exemption or modification termed to the length of the > > agreement? Or is it indefinite as long as the contracted party is > > located in the jurisdiction in question, or so long as the applicable > > law is in force. > > > > 5.2 Response:We agree with the European Commission in its response, > > > > ?/By logic the exemption or modification shall be in place as long as > > the party is subject to the jurisdiction in conflict with ICANN rules. > > If the applicable law was to change, or the contacted party moved to a > > different jurisdiction, the conditions should be reviewed to assess if > > the exemption is still justified.?/ > > > > // > > > > But provided it is the same parties, operating under the same laws, > > the modification or change should continue through the duration of the > > relationship between the Registry/Registrar and ICANN. > > > > 5.3Should an exemption or modification based on the same laws and > > facts then be granted to other affected contracted parties in the same > > jurisdiction without invoking the Whois Procedure. > > > > 5.3 Response. The European Commission in its comments wrote, and we > > strongly agree: /?the same exception should apply to others in the > > same jurisdiction who can demonstrate that they are in the same > > situation.? /Further, Blacknight wrote and we support: /?if ANY > > registrar in Germany, for example, is granted a waiver based on German > > law, than ALL registrars based in Germany should receive the same > > treatment.? /Once a national data protection or privacy law is > > interpreted as requiring and exemption or modification, it should be > > available to all Registries/Registrars in that country. > > > > Further, we recommend that ICANN should be required to notify each > > gTLD Registry and Registrar in the same jurisdiction as that of the > > decision so they will have notice of the change. > > > > We thank ICANN staff for holding this comment period. > > > > Respectfully submitted, > > > > Rafik Dammak > > > > Chairman, NCSG > > > > On behalf of the Noncommercial Stakeholders Group > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NSCG Draft Comments for Review of WHOIS Consensus Procedure NCSG Edits6(00690163).doc Type: application/msword Size: 70144 bytes Desc: not available URL: From rafik.dammak Fri Aug 1 14:20:40 2014 From: rafik.dammak (Rafik Dammak) Date: Fri, 1 Aug 2014 20:20:40 +0900 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: <53DB6AE6.8040008@mail.utoronto.ca> References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: Thanks Stephanie for the edits and merging the comments. @Maria can you please make the call for consensus. I think Avri agrees with the changes but she will confirm that. we have less than 12 hours to submit the comments. Rafik 2014-08-01 19:24 GMT+09:00 Stephanie Perrin < stephanie.perrin at mail.utoronto.ca>: > Thanks for sending, I am having trouble with attachments but I got it. I > think I have made all the corrections now, here is the amended version 6, I > believe you can post it. > cheers Stephanie > > On 2014-08-01, 6:11, Rafik Dammak wrote: > > Hi Stephanie, > > I think joy included her language in the attached document, can you please > merge that with the latest draft you circulated? > Lesson learned: using a shared online document and avoid the word document > versioning nightmare. > > Best, > > Rafik > ---------- Forwarded message ---------- > From: "joy" > Date: Jul 31, 2014 3:05 AM > Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding > To: > Cc: > > Hi - thanks everyone for the effort on this > I have also added some information on the recent report of the UN High > Commissioner for Human Rights on the right to privacy in the digital age > - which includes aspects relevant for companies - plus one or two other > minor comments > Hope you get these in time! > Joy > > On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: > > Hi All, > > Attached is the revised version of the comments. It has the changes of > > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's > > signature and submission on behalf of the NCSG (feel free to add an > > electronic signature, Rafik!). (Track changes version showing edits > > attached) > > > > If you could please use _this version _of the revised comments for > > review and submission, that would be great. > > Best, > > Kathy > > > > > > > ----------------------------------------------------------------------------------------------------------------------------------------------- > > > > NCSG Response to the Questions of the > > > > /Review of the ICANN Procedure for Handling WHOIS Conflicts with > > Privacy Law / > > > > > https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// > > > > > > ** > > > > The Noncommercial Stakeholders Group represents noncommercial > > organizations and individual noncommercial users in their work in the > > policy and proceedings of ICANN and the GNSO. We respectfully submit > > as an opening premise that every legal business has the right and > > obligation to operate within the bounds and limits of its national > > laws and regulations. No legal business establishes itself to violate > > the law; and to do so is an invitation to civil and criminal > > penalties, in addition to reputational damage and a loss of the trust > > of their customers and business partner. ICANN Registries and > > Registrars are no different ? they want and need to abide by their laws. > > > > To that end, Registries and Registrars strive to comply with their > > national and local laws.They strive affirmatively and proactively to > > follow the laws and regulations under which they operate as legal > > entities. To do otherwise is to violate the purpose of a legal regime, > > to threaten the well being of the company, and to expose Directors, > > Officers and Employees to fines, jail, or civil litigation. In the > > matter of protection of personal and confidential information, which > > is a very newsworthy issue in the 21^st century, privacy practices are > > a matter of consumer trust, and therefore high risk for those > > operating an Internet business.Even if customers have obediently > > complied with demands for excessive collection and disclosure of > > personal information up to this point, in the current news furor over > > Snowden and the cooperation of business with national governments > > engaged in surveillance, this could change with the next news > > story.The Internet facilitates successful privacy campaigns. > > > > Thus, it is wise and timely for ICANN to raise the questions of this > > proceeding, /Review of the ICANN Procedure for Handling WHOIS > > Conflicts with Privacy Law/ (albeit at a busy time for the Community > > and at the height of summer; we expect to see more interest in this > > time towards the Fall and recommend that ICANN not construe the small > > number of comments received to date as a reflection of lack of > > interest). We submit these comments in response to the issues raises > > and the questions asked. > > > > *Background* > > > > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law > > /was adopted in 2006 after years of debate on Whois issues. This > > Consensus Procedure was the first step of recognition that data > > protection laws and privacy law DO apply to the personal and sensitive > > data being collected by Registries and Registrars for the Whois database. > > > > But for those of us in the Noncommercial Users Constituency (now part > > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft > > and adopt this Consensus Procedure in the mid-2000s, we were always > > shocked that the ICANN Community did not do more. At the time, several > > Whois Task Forces were at work with multiple proposals which include > > important and pro-active suggestions to allow Registrars and > > Registries to come into compliance with their national and local data > > protection and privacy laws. > > > > At the time, we never expected this Consensus Procedure to be an end > > itself ? but the first of many steps. We are glad the discussion is > > now reopened and we support empowering Registrars and Registries to be > > in full compliance with their national and local data protection, > > consumer protection and privacy laws ? from the moment they enter into > > their contracts with ICANN. > > > > We note there have been a number of recent decisions in higher courts > > in various jurisdictions which impact the constitutional rights of > > citizens to be free from warrantless disclosure and retention of their > > personal information for law enforcement purposes.This reflects the > > time it takes for data protection issues to wend their way to the high > > courts for a ruling.We would urge ICANN, who otherwise sit on the > > cutting edge of Internet technical issues, to reflect on their role as > > a key global player in Internet governance.Do we lead or do we wait > > until we are dragged into Court, to realize our responsibilities to > > protect the fundamental rights of the citizens who depend on the > > Internet to participate in modern society?// > > > > II. Data Protection and Privacy Laws ? A Quick Overview of the > > Principles that Protect the Personal and Sensitive Data of Individuals > > and Organizations/Small Businesses > > > > It is important to stress that while the discourse about data > > protection requirements at ICANN has tended to focus on the European > > Union and its Data Commissioners, as represented in the Article 29 > > Working Party on Data Protection, there are a great many countries > > which have data protection law in place, including Canada, Mexico, > > much of South America, Korea, Japan, Australia, New Zealand, > > Singapore, South Africa, and many others.It is therefore quite > > puzzling that ICANN does not assemble a working group to study the > > matter and develop a harmonized approach to the issue, rather than > > take this rather odd approach of forcing registrars and registries to > > break national and local law. > > > > It is also important to note that there are many levels of data > > protection law, from local municipal law to state and national > > law.There is also sectoral law which applies to certain sectors.It > > would be a reasonable approach to develop a policy that reflects > > harmonized best practice, and abide by the policy rather than engage > > in this adversarial approach to local law.Data protection law is > > overwhelmingly complaints based, so it is inherently difficult for > > registrars and registries to get a ruling from data protection > > commissioners absent a complaint and a set of facts. > > > > In this regard, we also find it puzzling that despite the fact that > > the Article 29 Working Party wrote to ICANN senior management to > > indicate that they have reviewed the matter and reached an opinion > > that the practices involving WHOIS do indeed violate EU law, ICANN has > > not taken that message and developed a policy that guides their data > > protection practices, starting with a clear statement of limited > > purpose for the collection, use, and disclosure of personal information. > > > > The NCSG held a privacy meeting at the London ICANN 50 meeting, which > > was quite well attended.While we did not specifically address or > > attempt to brainstorm this particular problem, we feel it is safe to > > summarize the following points: > > > > ?There is considerable interest, in civil society, in the protection > > of personal information at ICANN. > > > > ?Policies and procedures such as were developed for the 2013 RAA are > > very puzzling to those who are engaged in government and business in > > the privacy field.This is not 1995, when the EU Directive on data > > protection was passed and was still controversial.ICANN needs to catch > > up with global business practice, preferably by developing binding > > corporate rules which would take a harmonized approach to the > > differing local laws. It is not appropriate for all data protection to > > fall away in jurisdictions where there is not yet a data protection > > law that applies to the provision of internet services, including > > domain name registration. > > > > ?NCSG is ramping up a team of volunteers to provide more detailed > > expertise and input on a number of privacy and free speech > > issues.While civil society is inherently stretched and short of > > resources, this is an issue that they care deeply about, and our > > outreach has begun to bear fruit in engaging others who are outside > > the immediate sphere of ICANN membership.This is important as they are > > part of the constituency we seek to represent. > > > > ICANN spends considerable time on technical parameters, data accuracy, > > and retention.More time needs to be spent on data protection policy.In > > this respect, more expertise would be required as there is very little > > evidence of privacy expertise in the ICANN community. > > > > III*/./*Questions asked of the Community in this Proceeding > > > > The ICANN Review Paper raised a number of excellent questions. In > > keeping with the requirements of a Reply Period, these NCSG comments > > will address both our comments and those comments we particularly > > support in this proceeding. > > > > However we would first like to note that the paper appears to start > > from the position that the procedures involved in this waiver process > > simply need to be tweaked.Operating under the first principle that all > > business must comply with local law, there is a need for ICANN to > > embrace data protection law as a well recognized branch of law which > > codifies well recognized business best practices with respect to the > > confidentiality of customer data.We respectfully submit that, if ICANN > > had a professional privacy officer, it is highly unlikely that he/she > > would recommend to senior management that the current approach be > > entertained in 2014. > > > > 1.1Is it impractical for ICANN to require that a contracted party > > already haslitigation or a government proceeding initiated against it > > prior to being able to invoke the Whois Procedure? > > > > 1.1 Response: Yes, it is completely impractical (and ill-advised) to > > force a company to violate a national law as a condition of complying > > with their contract. Every lawyer advises businesses to comply with > > the laws and regulations of their field. To do otherwise is to face > > fines, penalties, loss of the business, even jail for officers and > > directors. Legal business strives to be law-abiding; no officer or > > director wants to go to jail for her company's violations. It is the > > essence of an attorney's advice to his/her clients to fully comply > > with the laws and operate clearly within the clear boundaries and > > limits of laws and regulations, both national, by province or state > > and local. > > > > In these Reply Comments, we support and encourage ICANN to adopt > > policies consistent with the initial comments submitted by the > > European Commission: > > > > -that the Whois Procedure be changed from requiring specific > > prosecutorial action instead to allowing ?demonstrating evidence of a > > potential conflict widely and e.g. accepting information on the > > legislation imposing requirements that the contractual requirements > > would breach as sufficient evidence.? (European Commission comments) > > > > We also agree with Blacknight: > > > > -?It's completely illogical for ICANN to require that a contracting > > party already has litigation before they can use a process. We would > > have loved to use a procedure or process to get exemptions, but > > expecting us to already be litigating before we can do so is, for lack > > of a better word, nuts.? (Blacknight comments in this proceeding). > > > > - > > > > 1.1a How can the triggering event be meaningfully defined? > > > > This is an important question. Rephrased, we might ask together ?what > > must a Registry or Registrar show ICANN in support of its claim that > > certain provisions involving Whois data violate provisions of national > > data protection and privacy laws? > > > > NCSG respectfully submits that there are at least four ?triggering > > events? that ICANN should recognize: > > > > -Evidence from a national Data Protection Commissioner or his/her > > office (or from a internationally recognized body of national Data > > Protection Commissioners in a certain region of the world, including > > the Article 29 Working Party that analyzes the national data > > protection and privacy laws) that ICANN's contractual obligations for > > Registry and/or Registrar contracts violate the data protection laws > > of their country or their group of countries; > > > > -Evidence of legal and/or jurisdictional conflict arising from > > analysis performed by ICANN's legal department or by national legal > > experts hired by ICANN to evaluate the Whois requirements of the ICANN > > contracts for compliance and conflicts with national data protection > > laws and cross-border transfer limits) (similar to the process we > > understand was undertaken for the data retention issue); > > > > -Receipt of a written legal opinion from a nationally recognized law > > firm or qualified legal practitioner in the applicable jurisdiction > > that states that the collection, retention and/or transfer of certain > > Whois data elements as required by Registrar or Registry Agreements is > > ?reasonably likely to violate the applicable law? of the Registry or > > Registrar (per the process allowed in RAA Data Retention > > Specification); or > > > > -An official opinion of any other governmental body of competent > > jurisdiction providing that compliance with the data protection > > requirements of the Registry/Registrar contracts violates applicable > > national law (although such pro-active opinions may not be the > > practice of the Data Protection Commissioner's office). > > > > The above list draws from the comments of the European Commission, > > Data Retention Specification of the 2013Registrar Accreditation > > Agreement, and sound compliance and business practices for the ICANN > > General Counsel's office. > > > > We further agree with Blacknight that the requirements for triggering > > any review and consideration by ICANN be: simple and straightforward, > > quick and easy to access. > > > > 1.3Are there any components of the triggering event/notification > > portion of the RAA's Data Retention waiver process that should be > > considered as optional for incorporation into a modified Whois Procedure? > > > > 1.3 Response:Absolutely, the full list in 1.1a above, together with > > other constructive contributions in the Comments and Reply Comments of > > this proceeding, should be strongly considered for incorporation into > > a modified Whois Procedure, or simply written into the contracts of > > the Registries and Registrars contractual language, or a new Annex or > > Specification. > > > > We respectfully submit that the obligation of Registries and > > Registrars to comply with their national laws is not a matter of > > multistakeholder decision making, but a matter of law and compliance. > > In this case, we wholeheartedly embrace the concept of building a > > process together that will allow exceptions for data protection and > > privacy laws to be adopted quickly and easily. > > > > 1.4Should parties be permitted to invoke the Whois Procedure before > > contracting with ICANN as a registrar or registry? > > > > 1.4 Response: Of course, Registries and Registrars should be allowed > > to invoke the Whois Procedure, or other appropriate annexes and > > specifications that may be added into Registry and Registrar contracts > > with ICANN. As discussed above, the right of a legal company to enter > > into a legal contracts is the most basic of expectations under law. > > > > 2.1Are there other relevant parties who should be included in this step? > > > > 2.1 Response: We agree with the EC that ICANN should be working as > > closely with National Data Protection Authorities as they will allow. > > In light of the overflow of work into these national commissions, and > > the availability of national experts at law firms, ICANN should also > > turn to the advice of private experts,such as well-respected law firms > > who specialize in national data protection laws. The law firm's > > opinions on these matters would help to guide ICANN's knowledge and > > evaluation of this important issue. > > > > 3.1How is an agreement reached and published? > > > > 3.1 Response. As discussed above, compliance with national law may not > > be the best matter for negotiation within a multistakeholder process. > > It really should not be a chose for others to make whether you comply > > with your national data protection and privacy laws. That said, the > > process of refining the Consensus Procedure, and adopting new policies > > and procedures, or simply putting new contract provisions, annexes or > > specifications into the Registry and Registrar contracts SHOULD be > > subject to community discussion, notification and review.But once the > > new process is adopted, we think the new changes, variations, > > modifications or exceptions of Individual Registries and Registrars > > need go through a public review and process. The results, however, > > Should be published for Community notification and review. > > > > We note that in conducting the discussion with the Community on the > > overall or general procedure, policy or contractual changes, ICANN > > should be assertive in its outreach to the Data Protection > > Commissioners. Individual and through their organizations, they have > > offered to help ICANN evaluate this issue numerous times. The Whois > > Review Team noted the inability of many external bodies to monitor > > ICANN regularly, but the need for outreach to them by ICANN staff > > nonetheless: > > > > *Recommendation 3:Outreach* > > > > *ICANN should ensure that WHOIS policy issues are accompanied by > > cross-community outreach, including outreach to the communities > > outside of ICANN with a specific interest in the issues, and an > > ongoing program for consumer awareness. (Whois Review Team Final Report)* > > > > This is a critical policy item for such outreach and input. > > > > 3.2If there is an agreed outcome among the relevant parties, should > > the Board be involved in this procedure? > > > > 3.2 Response: Clearly, the changing of the procedure, or the adoption > > of a new policy or new contractual language for Registries and > > Registrars, Board oversight and review should be involved. But once > > the new procedure, policy or contractual language is in place, then > > subsequent individual changes, variations, modifications or exceptions > > should be handled through the process and ICANN Staff ? as the Data > > Retention Process is handled today. > > > > 4.1Would it be fruitful to incorporate public comment in each of the > > resolution scenarios. > > > > 4.1 Response: We think this question means whether there should be > > public input on each and every exception?We respectfully submit that > > the answer is No. Once the new policy, procedure or contractual > > language is adopted, then the process should kick in and the > > Registrar/Registry should be allowed to apply for the waiver, > > modification or revision consistent with its data protection and > > privacy laws.Of course, once the waiver or modification is granted, > > the decision should be matter of public record so that other > > Registries and Registrars in the jurisdiction know and so that the > > ICANN Community as a whole can monitor this process' implementation > > and compliance. > > > > Step Five: Public notice > > > > 5.2Is the exemption or modification termed to the length of the > > agreement? Or is it indefinite as long as the contracted party is > > located in the jurisdiction in question, or so long as the applicable > > law is in force. > > > > 5.2 Response:We agree with the European Commission in its response, > > > > ?/By logic the exemption or modification shall be in place as long as > > the party is subject to the jurisdiction in conflict with ICANN rules. > > If the applicable law was to change, or the contacted party moved to a > > different jurisdiction, the conditions should be reviewed to assess if > > the exemption is still justified.?/ > > > > // > > > > But provided it is the same parties, operating under the same laws, > > the modification or change should continue through the duration of the > > relationship between the Registry/Registrar and ICANN. > > > > 5.3Should an exemption or modification based on the same laws and > > facts then be granted to other affected contracted parties in the same > > jurisdiction without invoking the Whois Procedure. > > > > 5.3 Response. The European Commission in its comments wrote, and we > > strongly agree: /?the same exception should apply to others in the > > same jurisdiction who can demonstrate that they are in the same > > situation.? /Further, Blacknight wrote and we support: /?if ANY > > registrar in Germany, for example, is granted a waiver based on German > > law, than ALL registrars based in Germany should receive the same > > treatment.? /Once a national data protection or privacy law is > > interpreted as requiring and exemption or modification, it should be > > available to all Registries/Registrars in that country. > > > > Further, we recommend that ICANN should be required to notify each > > gTLD Registry and Registrar in the same jurisdiction as that of the > > decision so they will have notice of the change. > > > > We thank ICANN staff for holding this comment period. > > > > Respectfully submitted, > > > > Rafik Dammak > > > > Chairman, NCSG > > > > On behalf of the Noncommercial Stakeholders Group > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.farrell Fri Aug 1 14:26:04 2014 From: maria.farrell (Maria Farrell) Date: Fri, 1 Aug 2014 12:26:04 +0100 Subject: [PC-NCSG] [NCSG-Discuss] [urgent] Draft Comments for Whois Proceeding In-Reply-To: <53DB6611.6090606@mail.utoronto.ca> References: <53D8E4D0.8080805@acm.org> <53D8EBB3.7060404@acm.org> <5762B7A6-B931-4E7A-AD19-7B2D92944023@egyptig.org> <53DA44C7.7090700@mail.utoronto.ca> <53DA5C0F.9050401@kathykleiman.com> <53DA6724.20108@mail.utoronto.ca> <53DA7A94.2060606@yorku.ca> <53DB6611.6090606@mail.utoronto.ca> Message-ID: Hi all, With enormous thanks to the drafters and re-drafters, shocked and otherwise of this. Hereby the official final call on Stephanie's revised Draft 5; any final comments? This draft closes at 1500 UTC today. All the best, Maria On 1 August 2014 11:04, Stephanie Perrin wrote: > Thanks, Sam! Responses to your comments: > 1) I have discussed this a bit with Avri and I am reluctant to drop the > Snowden reference, even if it is a wee bit inflammatory....this is partly > because I am tired of talking in general terms about public policy, they > will simply interpret that as compliance with law enforcement demands, not > privacy expectations of consumers. > 2) agreed, I am tempted to say that in the comment but resisting > 3) re the typos, I will have to go back, check the quotes, and square > bracket/sic them. thanks! > cheers stephanie > > On 2014-07-31, 13:19, Sam Lanfranco wrote: > > It is late in the time left for revising this document so I will just > offer three short comments without going in and attempting to wordsmith > inside the document. Food for though! > > #1: Page 1: As part of the opening logic to the submission the text as > written is: > > *In the matter of protection of personal and confidential information, > which is a very newsworthy issue in the 21st century, privacy practices are > a matter of consumer trust, and therefore high risk for those operating an > Internet business. Even if customers have obediently complied with demands > for excessive collection and disclosure of personal information up to this > point, in the current news furor over Snowden and the cooperation of > business with national governments engaged in surveillance, this could > change with the next news story. The Internet facilitates successful > privacy campaigns.* > > I would suggest that the submission focus in immediately on ICANN practice > and evolving policy on the protection of personal and confidential > information, and not so much Snowden and news stories. > > [Possible revision] > > *In the matter of protection of personal and confidential information on > the Internet social norms and public policy are evolving and ICANN should > be in the forefront of helping define workable practice, as well as > bringing its contract language in line with public policy. It is bad ICANN > business practice to put registrars at odds with national privacy policy. > It also jeopardizes registrars? consumer trust and puts at risk the > business of those operating an Internet business. * > > #2: [Comment] There is a saying about the Catholic Church, to the effect > that dealing with social norms it always arrives a little late and out of > breath. ICANN is acting in a similar way. ICANN could both handle this in > contract language, and help evolve best and workable practices around the > protection of personal and confidential information by (a) contract > language that is consistent with national policy, and (b) showing some > leadership in what would be good and workable policy here. ICANN is neither > a King nor a Church bestowing favors on registries and registrars. It is a > business entering into contractual obligations with its direct customers. > > #3: [*Typo*] I don?t know if the typo is in the Blacknight quote or not, > but 5.3 should read ?., then [not than] ALL registrars based in Germany?? > > 5.3 Response. The European Commission in its comments wrote, and we > strongly agree: ?the same exception should apply to others in the same > jurisdiction who can demonstrate that they are in the same situation.? > Further, Blacknight wrote and we support: ?if ANY registrar in Germany, for > example, is granted a waiver based on German law, *then* ALL registrars > based in Germany should receive the same treatment.? Once a national data > protection or privacy law is interpreted as requiring and exemption or > modification, it should be available to all Registries/Registrars in that > country. > > Sam L. > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.farrell Fri Aug 1 14:27:46 2014 From: maria.farrell (Maria Farrell) Date: Fri, 1 Aug 2014 12:27:46 +0100 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: My apologies, I made the call for consensus on the next-to-final draft. Draft 6, what should be the final draft, closes for comments at 1500 UTC today. Speak now or hold your peace, colleagues. All the best, Maria On 1 August 2014 12:20, Rafik Dammak wrote: > Thanks Stephanie for the edits and merging the comments. > @Maria can you please make the call for consensus. I think Avri agrees > with the changes but she will confirm that. > we have less than 12 hours to submit the comments. > > Rafik > > 2014-08-01 19:24 GMT+09:00 Stephanie Perrin < > stephanie.perrin at mail.utoronto.ca>: > > Thanks for sending, I am having trouble with attachments but I got it. >> I think I have made all the corrections now, here is the amended version 6, >> I believe you can post it. >> cheers Stephanie >> >> On 2014-08-01, 6:11, Rafik Dammak wrote: >> >> Hi Stephanie, >> >> I think joy included her language in the attached document, can you >> please merge that with the latest draft you circulated? >> Lesson learned: using a shared online document and avoid the word >> document versioning nightmare. >> >> Best, >> >> Rafik >> ---------- Forwarded message ---------- >> From: "joy" >> Date: Jul 31, 2014 3:05 AM >> Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding >> To: >> Cc: >> >> Hi - thanks everyone for the effort on this >> I have also added some information on the recent report of the UN High >> Commissioner for Human Rights on the right to privacy in the digital age >> - which includes aspects relevant for companies - plus one or two other >> minor comments >> Hope you get these in time! >> Joy >> >> On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: >> > Hi All, >> > Attached is the revised version of the comments. It has the changes of >> > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's >> > signature and submission on behalf of the NCSG (feel free to add an >> > electronic signature, Rafik!). (Track changes version showing edits >> > attached) >> > >> > If you could please use _this version _of the revised comments for >> > review and submission, that would be great. >> > Best, >> > Kathy >> > >> > >> > >> ----------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > NCSG Response to the Questions of the >> > >> > /Review of the ICANN Procedure for Handling WHOIS Conflicts with >> > Privacy Law / >> > >> > >> https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// >> > >> > >> > ** >> > >> > The Noncommercial Stakeholders Group represents noncommercial >> > organizations and individual noncommercial users in their work in the >> > policy and proceedings of ICANN and the GNSO. We respectfully submit >> > as an opening premise that every legal business has the right and >> > obligation to operate within the bounds and limits of its national >> > laws and regulations. No legal business establishes itself to violate >> > the law; and to do so is an invitation to civil and criminal >> > penalties, in addition to reputational damage and a loss of the trust >> > of their customers and business partner. ICANN Registries and >> > Registrars are no different ? they want and need to abide by their laws. >> > >> > To that end, Registries and Registrars strive to comply with their >> > national and local laws.They strive affirmatively and proactively to >> > follow the laws and regulations under which they operate as legal >> > entities. To do otherwise is to violate the purpose of a legal regime, >> > to threaten the well being of the company, and to expose Directors, >> > Officers and Employees to fines, jail, or civil litigation. In the >> > matter of protection of personal and confidential information, which >> > is a very newsworthy issue in the 21^st century, privacy practices are >> > a matter of consumer trust, and therefore high risk for those >> > operating an Internet business.Even if customers have obediently >> > complied with demands for excessive collection and disclosure of >> > personal information up to this point, in the current news furor over >> > Snowden and the cooperation of business with national governments >> > engaged in surveillance, this could change with the next news >> > story.The Internet facilitates successful privacy campaigns. >> > >> > Thus, it is wise and timely for ICANN to raise the questions of this >> > proceeding, /Review of the ICANN Procedure for Handling WHOIS >> > Conflicts with Privacy Law/ (albeit at a busy time for the Community >> > and at the height of summer; we expect to see more interest in this >> > time towards the Fall and recommend that ICANN not construe the small >> > number of comments received to date as a reflection of lack of >> > interest). We submit these comments in response to the issues raises >> > and the questions asked. >> > >> > *Background* >> > >> > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law >> > /was adopted in 2006 after years of debate on Whois issues. This >> > Consensus Procedure was the first step of recognition that data >> > protection laws and privacy law DO apply to the personal and sensitive >> > data being collected by Registries and Registrars for the Whois >> database. >> > >> > But for those of us in the Noncommercial Users Constituency (now part >> > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft >> > and adopt this Consensus Procedure in the mid-2000s, we were always >> > shocked that the ICANN Community did not do more. At the time, several >> > Whois Task Forces were at work with multiple proposals which include >> > important and pro-active suggestions to allow Registrars and >> > Registries to come into compliance with their national and local data >> > protection and privacy laws. >> > >> > At the time, we never expected this Consensus Procedure to be an end >> > itself ? but the first of many steps. We are glad the discussion is >> > now reopened and we support empowering Registrars and Registries to be >> > in full compliance with their national and local data protection, >> > consumer protection and privacy laws ? from the moment they enter into >> > their contracts with ICANN. >> > >> > We note there have been a number of recent decisions in higher courts >> > in various jurisdictions which impact the constitutional rights of >> > citizens to be free from warrantless disclosure and retention of their >> > personal information for law enforcement purposes.This reflects the >> > time it takes for data protection issues to wend their way to the high >> > courts for a ruling.We would urge ICANN, who otherwise sit on the >> > cutting edge of Internet technical issues, to reflect on their role as >> > a key global player in Internet governance.Do we lead or do we wait >> > until we are dragged into Court, to realize our responsibilities to >> > protect the fundamental rights of the citizens who depend on the >> > Internet to participate in modern society?// >> > >> > II. Data Protection and Privacy Laws ? A Quick Overview of the >> > Principles that Protect the Personal and Sensitive Data of Individuals >> > and Organizations/Small Businesses >> > >> > It is important to stress that while the discourse about data >> > protection requirements at ICANN has tended to focus on the European >> > Union and its Data Commissioners, as represented in the Article 29 >> > Working Party on Data Protection, there are a great many countries >> > which have data protection law in place, including Canada, Mexico, >> > much of South America, Korea, Japan, Australia, New Zealand, >> > Singapore, South Africa, and many others.It is therefore quite >> > puzzling that ICANN does not assemble a working group to study the >> > matter and develop a harmonized approach to the issue, rather than >> > take this rather odd approach of forcing registrars and registries to >> > break national and local law. >> > >> > It is also important to note that there are many levels of data >> > protection law, from local municipal law to state and national >> > law.There is also sectoral law which applies to certain sectors.It >> > would be a reasonable approach to develop a policy that reflects >> > harmonized best practice, and abide by the policy rather than engage >> > in this adversarial approach to local law.Data protection law is >> > overwhelmingly complaints based, so it is inherently difficult for >> > registrars and registries to get a ruling from data protection >> > commissioners absent a complaint and a set of facts. >> > >> > In this regard, we also find it puzzling that despite the fact that >> > the Article 29 Working Party wrote to ICANN senior management to >> > indicate that they have reviewed the matter and reached an opinion >> > that the practices involving WHOIS do indeed violate EU law, ICANN has >> > not taken that message and developed a policy that guides their data >> > protection practices, starting with a clear statement of limited >> > purpose for the collection, use, and disclosure of personal information. >> > >> > The NCSG held a privacy meeting at the London ICANN 50 meeting, which >> > was quite well attended.While we did not specifically address or >> > attempt to brainstorm this particular problem, we feel it is safe to >> > summarize the following points: >> > >> > ?There is considerable interest, in civil society, in the protection >> > of personal information at ICANN. >> > >> > ?Policies and procedures such as were developed for the 2013 RAA are >> > very puzzling to those who are engaged in government and business in >> > the privacy field.This is not 1995, when the EU Directive on data >> > protection was passed and was still controversial.ICANN needs to catch >> > up with global business practice, preferably by developing binding >> > corporate rules which would take a harmonized approach to the >> > differing local laws. It is not appropriate for all data protection to >> > fall away in jurisdictions where there is not yet a data protection >> > law that applies to the provision of internet services, including >> > domain name registration. >> > >> > ?NCSG is ramping up a team of volunteers to provide more detailed >> > expertise and input on a number of privacy and free speech >> > issues.While civil society is inherently stretched and short of >> > resources, this is an issue that they care deeply about, and our >> > outreach has begun to bear fruit in engaging others who are outside >> > the immediate sphere of ICANN membership.This is important as they are >> > part of the constituency we seek to represent. >> > >> > ICANN spends considerable time on technical parameters, data accuracy, >> > and retention.More time needs to be spent on data protection policy.In >> > this respect, more expertise would be required as there is very little >> > evidence of privacy expertise in the ICANN community. >> > >> > III*/./*Questions asked of the Community in this Proceeding >> > >> > The ICANN Review Paper raised a number of excellent questions. In >> > keeping with the requirements of a Reply Period, these NCSG comments >> > will address both our comments and those comments we particularly >> > support in this proceeding. >> > >> > However we would first like to note that the paper appears to start >> > from the position that the procedures involved in this waiver process >> > simply need to be tweaked.Operating under the first principle that all >> > business must comply with local law, there is a need for ICANN to >> > embrace data protection law as a well recognized branch of law which >> > codifies well recognized business best practices with respect to the >> > confidentiality of customer data.We respectfully submit that, if ICANN >> > had a professional privacy officer, it is highly unlikely that he/she >> > would recommend to senior management that the current approach be >> > entertained in 2014. >> > >> > 1.1Is it impractical for ICANN to require that a contracted party >> > already haslitigation or a government proceeding initiated against it >> > prior to being able to invoke the Whois Procedure? >> > >> > 1.1 Response: Yes, it is completely impractical (and ill-advised) to >> > force a company to violate a national law as a condition of complying >> > with their contract. Every lawyer advises businesses to comply with >> > the laws and regulations of their field. To do otherwise is to face >> > fines, penalties, loss of the business, even jail for officers and >> > directors. Legal business strives to be law-abiding; no officer or >> > director wants to go to jail for her company's violations. It is the >> > essence of an attorney's advice to his/her clients to fully comply >> > with the laws and operate clearly within the clear boundaries and >> > limits of laws and regulations, both national, by province or state >> > and local. >> > >> > In these Reply Comments, we support and encourage ICANN to adopt >> > policies consistent with the initial comments submitted by the >> > European Commission: >> > >> > -that the Whois Procedure be changed from requiring specific >> > prosecutorial action instead to allowing ?demonstrating evidence of a >> > potential conflict widely and e.g. accepting information on the >> > legislation imposing requirements that the contractual requirements >> > would breach as sufficient evidence.? (European Commission comments) >> > >> > We also agree with Blacknight: >> > >> > -?It's completely illogical for ICANN to require that a contracting >> > party already has litigation before they can use a process. We would >> > have loved to use a procedure or process to get exemptions, but >> > expecting us to already be litigating before we can do so is, for lack >> > of a better word, nuts.? (Blacknight comments in this proceeding). >> > >> > - >> > >> > 1.1a How can the triggering event be meaningfully defined? >> > >> > This is an important question. Rephrased, we might ask together ?what >> > must a Registry or Registrar show ICANN in support of its claim that >> > certain provisions involving Whois data violate provisions of national >> > data protection and privacy laws? >> > >> > NCSG respectfully submits that there are at least four ?triggering >> > events? that ICANN should recognize: >> > >> > -Evidence from a national Data Protection Commissioner or his/her >> > office (or from a internationally recognized body of national Data >> > Protection Commissioners in a certain region of the world, including >> > the Article 29 Working Party that analyzes the national data >> > protection and privacy laws) that ICANN's contractual obligations for >> > Registry and/or Registrar contracts violate the data protection laws >> > of their country or their group of countries; >> > >> > -Evidence of legal and/or jurisdictional conflict arising from >> > analysis performed by ICANN's legal department or by national legal >> > experts hired by ICANN to evaluate the Whois requirements of the ICANN >> > contracts for compliance and conflicts with national data protection >> > laws and cross-border transfer limits) (similar to the process we >> > understand was undertaken for the data retention issue); >> > >> > -Receipt of a written legal opinion from a nationally recognized law >> > firm or qualified legal practitioner in the applicable jurisdiction >> > that states that the collection, retention and/or transfer of certain >> > Whois data elements as required by Registrar or Registry Agreements is >> > ?reasonably likely to violate the applicable law? of the Registry or >> > Registrar (per the process allowed in RAA Data Retention >> > Specification); or >> > >> > -An official opinion of any other governmental body of competent >> > jurisdiction providing that compliance with the data protection >> > requirements of the Registry/Registrar contracts violates applicable >> > national law (although such pro-active opinions may not be the >> > practice of the Data Protection Commissioner's office). >> > >> > The above list draws from the comments of the European Commission, >> > Data Retention Specification of the 2013Registrar Accreditation >> > Agreement, and sound compliance and business practices for the ICANN >> > General Counsel's office. >> > >> > We further agree with Blacknight that the requirements for triggering >> > any review and consideration by ICANN be: simple and straightforward, >> > quick and easy to access. >> > >> > 1.3Are there any components of the triggering event/notification >> > portion of the RAA's Data Retention waiver process that should be >> > considered as optional for incorporation into a modified Whois >> Procedure? >> > >> > 1.3 Response:Absolutely, the full list in 1.1a above, together with >> > other constructive contributions in the Comments and Reply Comments of >> > this proceeding, should be strongly considered for incorporation into >> > a modified Whois Procedure, or simply written into the contracts of >> > the Registries and Registrars contractual language, or a new Annex or >> > Specification. >> > >> > We respectfully submit that the obligation of Registries and >> > Registrars to comply with their national laws is not a matter of >> > multistakeholder decision making, but a matter of law and compliance. >> > In this case, we wholeheartedly embrace the concept of building a >> > process together that will allow exceptions for data protection and >> > privacy laws to be adopted quickly and easily. >> > >> > 1.4Should parties be permitted to invoke the Whois Procedure before >> > contracting with ICANN as a registrar or registry? >> > >> > 1.4 Response: Of course, Registries and Registrars should be allowed >> > to invoke the Whois Procedure, or other appropriate annexes and >> > specifications that may be added into Registry and Registrar contracts >> > with ICANN. As discussed above, the right of a legal company to enter >> > into a legal contracts is the most basic of expectations under law. >> > >> > 2.1Are there other relevant parties who should be included in this step? >> > >> > 2.1 Response: We agree with the EC that ICANN should be working as >> > closely with National Data Protection Authorities as they will allow. >> > In light of the overflow of work into these national commissions, and >> > the availability of national experts at law firms, ICANN should also >> > turn to the advice of private experts,such as well-respected law firms >> > who specialize in national data protection laws. The law firm's >> > opinions on these matters would help to guide ICANN's knowledge and >> > evaluation of this important issue. >> > >> > 3.1How is an agreement reached and published? >> > >> > 3.1 Response. As discussed above, compliance with national law may not >> > be the best matter for negotiation within a multistakeholder process. >> > It really should not be a chose for others to make whether you comply >> > with your national data protection and privacy laws. That said, the >> > process of refining the Consensus Procedure, and adopting new policies >> > and procedures, or simply putting new contract provisions, annexes or >> > specifications into the Registry and Registrar contracts SHOULD be >> > subject to community discussion, notification and review.But once the >> > new process is adopted, we think the new changes, variations, >> > modifications or exceptions of Individual Registries and Registrars >> > need go through a public review and process. The results, however, >> > Should be published for Community notification and review. >> > >> > We note that in conducting the discussion with the Community on the >> > overall or general procedure, policy or contractual changes, ICANN >> > should be assertive in its outreach to the Data Protection >> > Commissioners. Individual and through their organizations, they have >> > offered to help ICANN evaluate this issue numerous times. The Whois >> > Review Team noted the inability of many external bodies to monitor >> > ICANN regularly, but the need for outreach to them by ICANN staff >> > nonetheless: >> > >> > *Recommendation 3:Outreach* >> > >> > *ICANN should ensure that WHOIS policy issues are accompanied by >> > cross-community outreach, including outreach to the communities >> > outside of ICANN with a specific interest in the issues, and an >> > ongoing program for consumer awareness. (Whois Review Team Final >> Report)* >> > >> > This is a critical policy item for such outreach and input. >> > >> > 3.2If there is an agreed outcome among the relevant parties, should >> > the Board be involved in this procedure? >> > >> > 3.2 Response: Clearly, the changing of the procedure, or the adoption >> > of a new policy or new contractual language for Registries and >> > Registrars, Board oversight and review should be involved. But once >> > the new procedure, policy or contractual language is in place, then >> > subsequent individual changes, variations, modifications or exceptions >> > should be handled through the process and ICANN Staff ? as the Data >> > Retention Process is handled today. >> > >> > 4.1Would it be fruitful to incorporate public comment in each of the >> > resolution scenarios. >> > >> > 4.1 Response: We think this question means whether there should be >> > public input on each and every exception?We respectfully submit that >> > the answer is No. Once the new policy, procedure or contractual >> > language is adopted, then the process should kick in and the >> > Registrar/Registry should be allowed to apply for the waiver, >> > modification or revision consistent with its data protection and >> > privacy laws.Of course, once the waiver or modification is granted, >> > the decision should be matter of public record so that other >> > Registries and Registrars in the jurisdiction know and so that the >> > ICANN Community as a whole can monitor this process' implementation >> > and compliance. >> > >> > Step Five: Public notice >> > >> > 5.2Is the exemption or modification termed to the length of the >> > agreement? Or is it indefinite as long as the contracted party is >> > located in the jurisdiction in question, or so long as the applicable >> > law is in force. >> > >> > 5.2 Response:We agree with the European Commission in its response, >> > >> > ?/By logic the exemption or modification shall be in place as long as >> > the party is subject to the jurisdiction in conflict with ICANN rules. >> > If the applicable law was to change, or the contacted party moved to a >> > different jurisdiction, the conditions should be reviewed to assess if >> > the exemption is still justified.?/ >> > >> > // >> > >> > But provided it is the same parties, operating under the same laws, >> > the modification or change should continue through the duration of the >> > relationship between the Registry/Registrar and ICANN. >> > >> > 5.3Should an exemption or modification based on the same laws and >> > facts then be granted to other affected contracted parties in the same >> > jurisdiction without invoking the Whois Procedure. >> > >> > 5.3 Response. The European Commission in its comments wrote, and we >> > strongly agree: /?the same exception should apply to others in the >> > same jurisdiction who can demonstrate that they are in the same >> > situation.? /Further, Blacknight wrote and we support: /?if ANY >> > registrar in Germany, for example, is granted a waiver based on German >> > law, than ALL registrars based in Germany should receive the same >> > treatment.? /Once a national data protection or privacy law is >> > interpreted as requiring and exemption or modification, it should be >> > available to all Registries/Registrars in that country. >> > >> > Further, we recommend that ICANN should be required to notify each >> > gTLD Registry and Registrar in the same jurisdiction as that of the >> > decision so they will have notice of the change. >> > >> > We thank ICANN staff for holding this comment period. >> > >> > Respectfully submitted, >> > >> > Rafik Dammak >> > >> > Chairman, NCSG >> > >> > On behalf of the Noncommercial Stakeholders Group >> > >> > >> > >> >> >> > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aelsadr Fri Aug 1 15:05:50 2014 From: aelsadr (Amr Elsadr) Date: Fri, 1 Aug 2014 14:05:50 +0200 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: Thanks to Kathy and everyone else who worked on this. I hope we can submit draft 6 as an NCSG statement. Thanks again. Amr On Aug 1, 2014, at 1:27 PM, Maria Farrell wrote: > My apologies, I made the call for consensus on the next-to-final draft. > > Draft 6, what should be the final draft, closes for comments at 1500 UTC today. > > Speak now or hold your peace, colleagues. > > All the best, Maria > > > On 1 August 2014 12:20, Rafik Dammak wrote: > Thanks Stephanie for the edits and merging the comments. > @Maria can you please make the call for consensus. I think Avri agrees with the changes but she will confirm that. > we have less than 12 hours to submit the comments. > > Rafik > > 2014-08-01 19:24 GMT+09:00 Stephanie Perrin : > > Thanks for sending, I am having trouble with attachments but I got it. I think I have made all the corrections now, here is the amended version 6, I believe you can post it. > cheers Stephanie > > On 2014-08-01, 6:11, Rafik Dammak wrote: >> Hi Stephanie, >> >> I think joy included her language in the attached document, can you please merge that with the latest draft you circulated? >> Lesson learned: using a shared online document and avoid the word document versioning nightmare. >> >> Best, >> >> Rafik >> >> ---------- Forwarded message ---------- >> From: "joy" >> Date: Jul 31, 2014 3:05 AM >> Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding >> To: >> Cc: >> >> Hi - thanks everyone for the effort on this >> I have also added some information on the recent report of the UN High >> Commissioner for Human Rights on the right to privacy in the digital age >> - which includes aspects relevant for companies - plus one or two other >> minor comments >> Hope you get these in time! >> Joy >> >> On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: >> > Hi All, >> > Attached is the revised version of the comments. It has the changes of >> > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's >> > signature and submission on behalf of the NCSG (feel free to add an >> > electronic signature, Rafik!). (Track changes version showing edits >> > attached) >> > >> > If you could please use _this version _of the revised comments for >> > review and submission, that would be great. >> > Best, >> > Kathy >> > >> > >> > ----------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > NCSG Response to the Questions of the >> > >> > /Review of the ICANN Procedure for Handling WHOIS Conflicts with >> > Privacy Law / >> > >> > https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// >> > >> > >> > ** >> > >> > The Noncommercial Stakeholders Group represents noncommercial >> > organizations and individual noncommercial users in their work in the >> > policy and proceedings of ICANN and the GNSO. We respectfully submit >> > as an opening premise that every legal business has the right and >> > obligation to operate within the bounds and limits of its national >> > laws and regulations. No legal business establishes itself to violate >> > the law; and to do so is an invitation to civil and criminal >> > penalties, in addition to reputational damage and a loss of the trust >> > of their customers and business partner. ICANN Registries and >> > Registrars are no different ? they want and need to abide by their laws. >> > >> > To that end, Registries and Registrars strive to comply with their >> > national and local laws.They strive affirmatively and proactively to >> > follow the laws and regulations under which they operate as legal >> > entities. To do otherwise is to violate the purpose of a legal regime, >> > to threaten the well being of the company, and to expose Directors, >> > Officers and Employees to fines, jail, or civil litigation. In the >> > matter of protection of personal and confidential information, which >> > is a very newsworthy issue in the 21^st century, privacy practices are >> > a matter of consumer trust, and therefore high risk for those >> > operating an Internet business.Even if customers have obediently >> > complied with demands for excessive collection and disclosure of >> > personal information up to this point, in the current news furor over >> > Snowden and the cooperation of business with national governments >> > engaged in surveillance, this could change with the next news >> > story.The Internet facilitates successful privacy campaigns. >> > >> > Thus, it is wise and timely for ICANN to raise the questions of this >> > proceeding, /Review of the ICANN Procedure for Handling WHOIS >> > Conflicts with Privacy Law/ (albeit at a busy time for the Community >> > and at the height of summer; we expect to see more interest in this >> > time towards the Fall and recommend that ICANN not construe the small >> > number of comments received to date as a reflection of lack of >> > interest). We submit these comments in response to the issues raises >> > and the questions asked. >> > >> > *Background* >> > >> > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law >> > /was adopted in 2006 after years of debate on Whois issues. This >> > Consensus Procedure was the first step of recognition that data >> > protection laws and privacy law DO apply to the personal and sensitive >> > data being collected by Registries and Registrars for the Whois database. >> > >> > But for those of us in the Noncommercial Users Constituency (now part >> > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft >> > and adopt this Consensus Procedure in the mid-2000s, we were always >> > shocked that the ICANN Community did not do more. At the time, several >> > Whois Task Forces were at work with multiple proposals which include >> > important and pro-active suggestions to allow Registrars and >> > Registries to come into compliance with their national and local data >> > protection and privacy laws. >> > >> > At the time, we never expected this Consensus Procedure to be an end >> > itself ? but the first of many steps. We are glad the discussion is >> > now reopened and we support empowering Registrars and Registries to be >> > in full compliance with their national and local data protection, >> > consumer protection and privacy laws ? from the moment they enter into >> > their contracts with ICANN. >> > >> > We note there have been a number of recent decisions in higher courts >> > in various jurisdictions which impact the constitutional rights of >> > citizens to be free from warrantless disclosure and retention of their >> > personal information for law enforcement purposes.This reflects the >> > time it takes for data protection issues to wend their way to the high >> > courts for a ruling.We would urge ICANN, who otherwise sit on the >> > cutting edge of Internet technical issues, to reflect on their role as >> > a key global player in Internet governance.Do we lead or do we wait >> > until we are dragged into Court, to realize our responsibilities to >> > protect the fundamental rights of the citizens who depend on the >> > Internet to participate in modern society?// >> > >> > II. Data Protection and Privacy Laws ? A Quick Overview of the >> > Principles that Protect the Personal and Sensitive Data of Individuals >> > and Organizations/Small Businesses >> > >> > It is important to stress that while the discourse about data >> > protection requirements at ICANN has tended to focus on the European >> > Union and its Data Commissioners, as represented in the Article 29 >> > Working Party on Data Protection, there are a great many countries >> > which have data protection law in place, including Canada, Mexico, >> > much of South America, Korea, Japan, Australia, New Zealand, >> > Singapore, South Africa, and many others.It is therefore quite >> > puzzling that ICANN does not assemble a working group to study the >> > matter and develop a harmonized approach to the issue, rather than >> > take this rather odd approach of forcing registrars and registries to >> > break national and local law. >> > >> > It is also important to note that there are many levels of data >> > protection law, from local municipal law to state and national >> > law.There is also sectoral law which applies to certain sectors.It >> > would be a reasonable approach to develop a policy that reflects >> > harmonized best practice, and abide by the policy rather than engage >> > in this adversarial approach to local law.Data protection law is >> > overwhelmingly complaints based, so it is inherently difficult for >> > registrars and registries to get a ruling from data protection >> > commissioners absent a complaint and a set of facts. >> > >> > In this regard, we also find it puzzling that despite the fact that >> > the Article 29 Working Party wrote to ICANN senior management to >> > indicate that they have reviewed the matter and reached an opinion >> > that the practices involving WHOIS do indeed violate EU law, ICANN has >> > not taken that message and developed a policy that guides their data >> > protection practices, starting with a clear statement of limited >> > purpose for the collection, use, and disclosure of personal information. >> > >> > The NCSG held a privacy meeting at the London ICANN 50 meeting, which >> > was quite well attended.While we did not specifically address or >> > attempt to brainstorm this particular problem, we feel it is safe to >> > summarize the following points: >> > >> > ?There is considerable interest, in civil society, in the protection >> > of personal information at ICANN. >> > >> > ?Policies and procedures such as were developed for the 2013 RAA are >> > very puzzling to those who are engaged in government and business in >> > the privacy field.This is not 1995, when the EU Directive on data >> > protection was passed and was still controversial.ICANN needs to catch >> > up with global business practice, preferably by developing binding >> > corporate rules which would take a harmonized approach to the >> > differing local laws. It is not appropriate for all data protection to >> > fall away in jurisdictions where there is not yet a data protection >> > law that applies to the provision of internet services, including >> > domain name registration. >> > >> > ?NCSG is ramping up a team of volunteers to provide more detailed >> > expertise and input on a number of privacy and free speech >> > issues.While civil society is inherently stretched and short of >> > resources, this is an issue that they care deeply about, and our >> > outreach has begun to bear fruit in engaging others who are outside >> > the immediate sphere of ICANN membership.This is important as they are >> > part of the constituency we seek to represent. >> > >> > ICANN spends considerable time on technical parameters, data accuracy, >> > and retention.More time needs to be spent on data protection policy.In >> > this respect, more expertise would be required as there is very little >> > evidence of privacy expertise in the ICANN community. >> > >> > III*/./*Questions asked of the Community in this Proceeding >> > >> > The ICANN Review Paper raised a number of excellent questions. In >> > keeping with the requirements of a Reply Period, these NCSG comments >> > will address both our comments and those comments we particularly >> > support in this proceeding. >> > >> > However we would first like to note that the paper appears to start >> > from the position that the procedures involved in this waiver process >> > simply need to be tweaked.Operating under the first principle that all >> > business must comply with local law, there is a need for ICANN to >> > embrace data protection law as a well recognized branch of law which >> > codifies well recognized business best practices with respect to the >> > confidentiality of customer data.We respectfully submit that, if ICANN >> > had a professional privacy officer, it is highly unlikely that he/she >> > would recommend to senior management that the current approach be >> > entertained in 2014. >> > >> > 1.1Is it impractical for ICANN to require that a contracted party >> > already haslitigation or a government proceeding initiated against it >> > prior to being able to invoke the Whois Procedure? >> > >> > 1.1 Response: Yes, it is completely impractical (and ill-advised) to >> > force a company to violate a national law as a condition of complying >> > with their contract. Every lawyer advises businesses to comply with >> > the laws and regulations of their field. To do otherwise is to face >> > fines, penalties, loss of the business, even jail for officers and >> > directors. Legal business strives to be law-abiding; no officer or >> > director wants to go to jail for her company's violations. It is the >> > essence of an attorney's advice to his/her clients to fully comply >> > with the laws and operate clearly within the clear boundaries and >> > limits of laws and regulations, both national, by province or state >> > and local. >> > >> > In these Reply Comments, we support and encourage ICANN to adopt >> > policies consistent with the initial comments submitted by the >> > European Commission: >> > >> > -that the Whois Procedure be changed from requiring specific >> > prosecutorial action instead to allowing ?demonstrating evidence of a >> > potential conflict widely and e.g. accepting information on the >> > legislation imposing requirements that the contractual requirements >> > would breach as sufficient evidence.? (European Commission comments) >> > >> > We also agree with Blacknight: >> > >> > -?It's completely illogical for ICANN to require that a contracting >> > party already has litigation before they can use a process. We would >> > have loved to use a procedure or process to get exemptions, but >> > expecting us to already be litigating before we can do so is, for lack >> > of a better word, nuts.? (Blacknight comments in this proceeding). >> > >> > - >> > >> > 1.1a How can the triggering event be meaningfully defined? >> > >> > This is an important question. Rephrased, we might ask together ?what >> > must a Registry or Registrar show ICANN in support of its claim that >> > certain provisions involving Whois data violate provisions of national >> > data protection and privacy laws? >> > >> > NCSG respectfully submits that there are at least four ?triggering >> > events? that ICANN should recognize: >> > >> > -Evidence from a national Data Protection Commissioner or his/her >> > office (or from a internationally recognized body of national Data >> > Protection Commissioners in a certain region of the world, including >> > the Article 29 Working Party that analyzes the national data >> > protection and privacy laws) that ICANN's contractual obligations for >> > Registry and/or Registrar contracts violate the data protection laws >> > of their country or their group of countries; >> > >> > -Evidence of legal and/or jurisdictional conflict arising from >> > analysis performed by ICANN's legal department or by national legal >> > experts hired by ICANN to evaluate the Whois requirements of the ICANN >> > contracts for compliance and conflicts with national data protection >> > laws and cross-border transfer limits) (similar to the process we >> > understand was undertaken for the data retention issue); >> > >> > -Receipt of a written legal opinion from a nationally recognized law >> > firm or qualified legal practitioner in the applicable jurisdiction >> > that states that the collection, retention and/or transfer of certain >> > Whois data elements as required by Registrar or Registry Agreements is >> > ?reasonably likely to violate the applicable law? of the Registry or >> > Registrar (per the process allowed in RAA Data Retention >> > Specification); or >> > >> > -An official opinion of any other governmental body of competent >> > jurisdiction providing that compliance with the data protection >> > requirements of the Registry/Registrar contracts violates applicable >> > national law (although such pro-active opinions may not be the >> > practice of the Data Protection Commissioner's office). >> > >> > The above list draws from the comments of the European Commission, >> > Data Retention Specification of the 2013Registrar Accreditation >> > Agreement, and sound compliance and business practices for the ICANN >> > General Counsel's office. >> > >> > We further agree with Blacknight that the requirements for triggering >> > any review and consideration by ICANN be: simple and straightforward, >> > quick and easy to access. >> > >> > 1.3Are there any components of the triggering event/notification >> > portion of the RAA's Data Retention waiver process that should be >> > considered as optional for incorporation into a modified Whois Procedure? >> > >> > 1.3 Response:Absolutely, the full list in 1.1a above, together with >> > other constructive contributions in the Comments and Reply Comments of >> > this proceeding, should be strongly considered for incorporation into >> > a modified Whois Procedure, or simply written into the contracts of >> > the Registries and Registrars contractual language, or a new Annex or >> > Specification. >> > >> > We respectfully submit that the obligation of Registries and >> > Registrars to comply with their national laws is not a matter of >> > multistakeholder decision making, but a matter of law and compliance. >> > In this case, we wholeheartedly embrace the concept of building a >> > process together that will allow exceptions for data protection and >> > privacy laws to be adopted quickly and easily. >> > >> > 1.4Should parties be permitted to invoke the Whois Procedure before >> > contracting with ICANN as a registrar or registry? >> > >> > 1.4 Response: Of course, Registries and Registrars should be allowed >> > to invoke the Whois Procedure, or other appropriate annexes and >> > specifications that may be added into Registry and Registrar contracts >> > with ICANN. As discussed above, the right of a legal company to enter >> > into a legal contracts is the most basic of expectations under law. >> > >> > 2.1Are there other relevant parties who should be included in this step? >> > >> > 2.1 Response: We agree with the EC that ICANN should be working as >> > closely with National Data Protection Authorities as they will allow. >> > In light of the overflow of work into these national commissions, and >> > the availability of national experts at law firms, ICANN should also >> > turn to the advice of private experts,such as well-respected law firms >> > who specialize in national data protection laws. The law firm's >> > opinions on these matters would help to guide ICANN's knowledge and >> > evaluation of this important issue. >> > >> > 3.1How is an agreement reached and published? >> > >> > 3.1 Response. As discussed above, compliance with national law may not >> > be the best matter for negotiation within a multistakeholder process. >> > It really should not be a chose for others to make whether you comply >> > with your national data protection and privacy laws. That said, the >> > process of refining the Consensus Procedure, and adopting new policies >> > and procedures, or simply putting new contract provisions, annexes or >> > specifications into the Registry and Registrar contracts SHOULD be >> > subject to community discussion, notification and review.But once the >> > new process is adopted, we think the new changes, variations, >> > modifications or exceptions of Individual Registries and Registrars >> > need go through a public review and process. The results, however, >> > Should be published for Community notification and review. >> > >> > We note that in conducting the discussion with the Community on the >> > overall or general procedure, policy or contractual changes, ICANN >> > should be assertive in its outreach to the Data Protection >> > Commissioners. Individual and through their organizations, they have >> > offered to help ICANN evaluate this issue numerous times. The Whois >> > Review Team noted the inability of many external bodies to monitor >> > ICANN regularly, but the need for outreach to them by ICANN staff >> > nonetheless: >> > >> > *Recommendation 3:Outreach* >> > >> > *ICANN should ensure that WHOIS policy issues are accompanied by >> > cross-community outreach, including outreach to the communities >> > outside of ICANN with a specific interest in the issues, and an >> > ongoing program for consumer awareness. (Whois Review Team Final Report)* >> > >> > This is a critical policy item for such outreach and input. >> > >> > 3.2If there is an agreed outcome among the relevant parties, should >> > the Board be involved in this procedure? >> > >> > 3.2 Response: Clearly, the changing of the procedure, or the adoption >> > of a new policy or new contractual language for Registries and >> > Registrars, Board oversight and review should be involved. But once >> > the new procedure, policy or contractual language is in place, then >> > subsequent individual changes, variations, modifications or exceptions >> > should be handled through the process and ICANN Staff ? as the Data >> > Retention Process is handled today. >> > >> > 4.1Would it be fruitful to incorporate public comment in each of the >> > resolution scenarios. >> > >> > 4.1 Response: We think this question means whether there should be >> > public input on each and every exception?We respectfully submit that >> > the answer is No. Once the new policy, procedure or contractual >> > language is adopted, then the process should kick in and the >> > Registrar/Registry should be allowed to apply for the waiver, >> > modification or revision consistent with its data protection and >> > privacy laws.Of course, once the waiver or modification is granted, >> > the decision should be matter of public record so that other >> > Registries and Registrars in the jurisdiction know and so that the >> > ICANN Community as a whole can monitor this process' implementation >> > and compliance. >> > >> > Step Five: Public notice >> > >> > 5.2Is the exemption or modification termed to the length of the >> > agreement? Or is it indefinite as long as the contracted party is >> > located in the jurisdiction in question, or so long as the applicable >> > law is in force. >> > >> > 5.2 Response:We agree with the European Commission in its response, >> > >> > ?/By logic the exemption or modification shall be in place as long as >> > the party is subject to the jurisdiction in conflict with ICANN rules. >> > If the applicable law was to change, or the contacted party moved to a >> > different jurisdiction, the conditions should be reviewed to assess if >> > the exemption is still justified.?/ >> > >> > // >> > >> > But provided it is the same parties, operating under the same laws, >> > the modification or change should continue through the duration of the >> > relationship between the Registry/Registrar and ICANN. >> > >> > 5.3Should an exemption or modification based on the same laws and >> > facts then be granted to other affected contracted parties in the same >> > jurisdiction without invoking the Whois Procedure. >> > >> > 5.3 Response. The European Commission in its comments wrote, and we >> > strongly agree: /?the same exception should apply to others in the >> > same jurisdiction who can demonstrate that they are in the same >> > situation.? /Further, Blacknight wrote and we support: /?if ANY >> > registrar in Germany, for example, is granted a waiver based on German >> > law, than ALL registrars based in Germany should receive the same >> > treatment.? /Once a national data protection or privacy law is >> > interpreted as requiring and exemption or modification, it should be >> > available to all Registries/Registrars in that country. >> > >> > Further, we recommend that ICANN should be required to notify each >> > gTLD Registry and Registrar in the same jurisdiction as that of the >> > decision so they will have notice of the change. >> > >> > We thank ICANN staff for holding this comment period. >> > >> > Respectfully submitted, >> > >> > Rafik Dammak >> > >> > Chairman, NCSG >> > >> > On behalf of the Noncommercial Stakeholders Group >> > >> > >> > >> > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Fri Aug 1 21:34:25 2014 From: rafik.dammak (Rafik Dammak) Date: Sat, 2 Aug 2014 03:34:25 +0900 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: Hi Maria, thank you, I think we already passed the deadline for comment, can we consider that the comments are endorsed and ready to be submitted? Best, Rafik 2014-08-01 20:27 GMT+09:00 Maria Farrell : > My apologies, I made the call for consensus on the next-to-final draft. > > Draft 6, what should be the final draft, closes for comments at 1500 UTC > today. > > Speak now or hold your peace, colleagues. > > All the best, Maria > > > On 1 August 2014 12:20, Rafik Dammak wrote: > >> Thanks Stephanie for the edits and merging the comments. >> @Maria can you please make the call for consensus. I think Avri agrees >> with the changes but she will confirm that. >> we have less than 12 hours to submit the comments. >> >> Rafik >> >> 2014-08-01 19:24 GMT+09:00 Stephanie Perrin < >> stephanie.perrin at mail.utoronto.ca>: >> >> Thanks for sending, I am having trouble with attachments but I got it. >>> I think I have made all the corrections now, here is the amended version 6, >>> I believe you can post it. >>> cheers Stephanie >>> >>> On 2014-08-01, 6:11, Rafik Dammak wrote: >>> >>> Hi Stephanie, >>> >>> I think joy included her language in the attached document, can you >>> please merge that with the latest draft you circulated? >>> Lesson learned: using a shared online document and avoid the word >>> document versioning nightmare. >>> >>> Best, >>> >>> Rafik >>> ---------- Forwarded message ---------- >>> From: "joy" >>> Date: Jul 31, 2014 3:05 AM >>> Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding >>> To: >>> Cc: >>> >>> Hi - thanks everyone for the effort on this >>> I have also added some information on the recent report of the UN High >>> Commissioner for Human Rights on the right to privacy in the digital age >>> - which includes aspects relevant for companies - plus one or two other >>> minor comments >>> Hope you get these in time! >>> Joy >>> >>> On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: >>> > Hi All, >>> > Attached is the revised version of the comments. It has the changes of >>> > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's >>> > signature and submission on behalf of the NCSG (feel free to add an >>> > electronic signature, Rafik!). (Track changes version showing edits >>> > attached) >>> > >>> > If you could please use _this version _of the revised comments for >>> > review and submission, that would be great. >>> > Best, >>> > Kathy >>> > >>> > >>> > >>> ----------------------------------------------------------------------------------------------------------------------------------------------- >>> > >>> > NCSG Response to the Questions of the >>> > >>> > /Review of the ICANN Procedure for Handling WHOIS Conflicts with >>> > Privacy Law / >>> > >>> > >>> https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// >>> > >>> > >>> > ** >>> > >>> > The Noncommercial Stakeholders Group represents noncommercial >>> > organizations and individual noncommercial users in their work in the >>> > policy and proceedings of ICANN and the GNSO. We respectfully submit >>> > as an opening premise that every legal business has the right and >>> > obligation to operate within the bounds and limits of its national >>> > laws and regulations. No legal business establishes itself to violate >>> > the law; and to do so is an invitation to civil and criminal >>> > penalties, in addition to reputational damage and a loss of the trust >>> > of their customers and business partner. ICANN Registries and >>> > Registrars are no different ? they want and need to abide by their >>> laws. >>> > >>> > To that end, Registries and Registrars strive to comply with their >>> > national and local laws.They strive affirmatively and proactively to >>> > follow the laws and regulations under which they operate as legal >>> > entities. To do otherwise is to violate the purpose of a legal regime, >>> > to threaten the well being of the company, and to expose Directors, >>> > Officers and Employees to fines, jail, or civil litigation. In the >>> > matter of protection of personal and confidential information, which >>> > is a very newsworthy issue in the 21^st century, privacy practices are >>> > a matter of consumer trust, and therefore high risk for those >>> > operating an Internet business.Even if customers have obediently >>> > complied with demands for excessive collection and disclosure of >>> > personal information up to this point, in the current news furor over >>> > Snowden and the cooperation of business with national governments >>> > engaged in surveillance, this could change with the next news >>> > story.The Internet facilitates successful privacy campaigns. >>> > >>> > Thus, it is wise and timely for ICANN to raise the questions of this >>> > proceeding, /Review of the ICANN Procedure for Handling WHOIS >>> > Conflicts with Privacy Law/ (albeit at a busy time for the Community >>> > and at the height of summer; we expect to see more interest in this >>> > time towards the Fall and recommend that ICANN not construe the small >>> > number of comments received to date as a reflection of lack of >>> > interest). We submit these comments in response to the issues raises >>> > and the questions asked. >>> > >>> > *Background* >>> > >>> > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law >>> > /was adopted in 2006 after years of debate on Whois issues. This >>> > Consensus Procedure was the first step of recognition that data >>> > protection laws and privacy law DO apply to the personal and sensitive >>> > data being collected by Registries and Registrars for the Whois >>> database. >>> > >>> > But for those of us in the Noncommercial Users Constituency (now part >>> > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft >>> > and adopt this Consensus Procedure in the mid-2000s, we were always >>> > shocked that the ICANN Community did not do more. At the time, several >>> > Whois Task Forces were at work with multiple proposals which include >>> > important and pro-active suggestions to allow Registrars and >>> > Registries to come into compliance with their national and local data >>> > protection and privacy laws. >>> > >>> > At the time, we never expected this Consensus Procedure to be an end >>> > itself ? but the first of many steps. We are glad the discussion is >>> > now reopened and we support empowering Registrars and Registries to be >>> > in full compliance with their national and local data protection, >>> > consumer protection and privacy laws ? from the moment they enter into >>> > their contracts with ICANN. >>> > >>> > We note there have been a number of recent decisions in higher courts >>> > in various jurisdictions which impact the constitutional rights of >>> > citizens to be free from warrantless disclosure and retention of their >>> > personal information for law enforcement purposes.This reflects the >>> > time it takes for data protection issues to wend their way to the high >>> > courts for a ruling.We would urge ICANN, who otherwise sit on the >>> > cutting edge of Internet technical issues, to reflect on their role as >>> > a key global player in Internet governance.Do we lead or do we wait >>> > until we are dragged into Court, to realize our responsibilities to >>> > protect the fundamental rights of the citizens who depend on the >>> > Internet to participate in modern society?// >>> > >>> > II. Data Protection and Privacy Laws ? A Quick Overview of the >>> > Principles that Protect the Personal and Sensitive Data of Individuals >>> > and Organizations/Small Businesses >>> > >>> > It is important to stress that while the discourse about data >>> > protection requirements at ICANN has tended to focus on the European >>> > Union and its Data Commissioners, as represented in the Article 29 >>> > Working Party on Data Protection, there are a great many countries >>> > which have data protection law in place, including Canada, Mexico, >>> > much of South America, Korea, Japan, Australia, New Zealand, >>> > Singapore, South Africa, and many others.It is therefore quite >>> > puzzling that ICANN does not assemble a working group to study the >>> > matter and develop a harmonized approach to the issue, rather than >>> > take this rather odd approach of forcing registrars and registries to >>> > break national and local law. >>> > >>> > It is also important to note that there are many levels of data >>> > protection law, from local municipal law to state and national >>> > law.There is also sectoral law which applies to certain sectors.It >>> > would be a reasonable approach to develop a policy that reflects >>> > harmonized best practice, and abide by the policy rather than engage >>> > in this adversarial approach to local law.Data protection law is >>> > overwhelmingly complaints based, so it is inherently difficult for >>> > registrars and registries to get a ruling from data protection >>> > commissioners absent a complaint and a set of facts. >>> > >>> > In this regard, we also find it puzzling that despite the fact that >>> > the Article 29 Working Party wrote to ICANN senior management to >>> > indicate that they have reviewed the matter and reached an opinion >>> > that the practices involving WHOIS do indeed violate EU law, ICANN has >>> > not taken that message and developed a policy that guides their data >>> > protection practices, starting with a clear statement of limited >>> > purpose for the collection, use, and disclosure of personal >>> information. >>> > >>> > The NCSG held a privacy meeting at the London ICANN 50 meeting, which >>> > was quite well attended.While we did not specifically address or >>> > attempt to brainstorm this particular problem, we feel it is safe to >>> > summarize the following points: >>> > >>> > ?There is considerable interest, in civil society, in the protection >>> > of personal information at ICANN. >>> > >>> > ?Policies and procedures such as were developed for the 2013 RAA are >>> > very puzzling to those who are engaged in government and business in >>> > the privacy field.This is not 1995, when the EU Directive on data >>> > protection was passed and was still controversial.ICANN needs to catch >>> > up with global business practice, preferably by developing binding >>> > corporate rules which would take a harmonized approach to the >>> > differing local laws. It is not appropriate for all data protection to >>> > fall away in jurisdictions where there is not yet a data protection >>> > law that applies to the provision of internet services, including >>> > domain name registration. >>> > >>> > ?NCSG is ramping up a team of volunteers to provide more detailed >>> > expertise and input on a number of privacy and free speech >>> > issues.While civil society is inherently stretched and short of >>> > resources, this is an issue that they care deeply about, and our >>> > outreach has begun to bear fruit in engaging others who are outside >>> > the immediate sphere of ICANN membership.This is important as they are >>> > part of the constituency we seek to represent. >>> > >>> > ICANN spends considerable time on technical parameters, data accuracy, >>> > and retention.More time needs to be spent on data protection policy.In >>> > this respect, more expertise would be required as there is very little >>> > evidence of privacy expertise in the ICANN community. >>> > >>> > III*/./*Questions asked of the Community in this Proceeding >>> > >>> > The ICANN Review Paper raised a number of excellent questions. In >>> > keeping with the requirements of a Reply Period, these NCSG comments >>> > will address both our comments and those comments we particularly >>> > support in this proceeding. >>> > >>> > However we would first like to note that the paper appears to start >>> > from the position that the procedures involved in this waiver process >>> > simply need to be tweaked.Operating under the first principle that all >>> > business must comply with local law, there is a need for ICANN to >>> > embrace data protection law as a well recognized branch of law which >>> > codifies well recognized business best practices with respect to the >>> > confidentiality of customer data.We respectfully submit that, if ICANN >>> > had a professional privacy officer, it is highly unlikely that he/she >>> > would recommend to senior management that the current approach be >>> > entertained in 2014. >>> > >>> > 1.1Is it impractical for ICANN to require that a contracted party >>> > already haslitigation or a government proceeding initiated against it >>> > prior to being able to invoke the Whois Procedure? >>> > >>> > 1.1 Response: Yes, it is completely impractical (and ill-advised) to >>> > force a company to violate a national law as a condition of complying >>> > with their contract. Every lawyer advises businesses to comply with >>> > the laws and regulations of their field. To do otherwise is to face >>> > fines, penalties, loss of the business, even jail for officers and >>> > directors. Legal business strives to be law-abiding; no officer or >>> > director wants to go to jail for her company's violations. It is the >>> > essence of an attorney's advice to his/her clients to fully comply >>> > with the laws and operate clearly within the clear boundaries and >>> > limits of laws and regulations, both national, by province or state >>> > and local. >>> > >>> > In these Reply Comments, we support and encourage ICANN to adopt >>> > policies consistent with the initial comments submitted by the >>> > European Commission: >>> > >>> > -that the Whois Procedure be changed from requiring specific >>> > prosecutorial action instead to allowing ?demonstrating evidence of a >>> > potential conflict widely and e.g. accepting information on the >>> > legislation imposing requirements that the contractual requirements >>> > would breach as sufficient evidence.? (European Commission comments) >>> > >>> > We also agree with Blacknight: >>> > >>> > -?It's completely illogical for ICANN to require that a contracting >>> > party already has litigation before they can use a process. We would >>> > have loved to use a procedure or process to get exemptions, but >>> > expecting us to already be litigating before we can do so is, for lack >>> > of a better word, nuts.? (Blacknight comments in this proceeding). >>> > >>> > - >>> > >>> > 1.1a How can the triggering event be meaningfully defined? >>> > >>> > This is an important question. Rephrased, we might ask together ?what >>> > must a Registry or Registrar show ICANN in support of its claim that >>> > certain provisions involving Whois data violate provisions of national >>> > data protection and privacy laws? >>> > >>> > NCSG respectfully submits that there are at least four ?triggering >>> > events? that ICANN should recognize: >>> > >>> > -Evidence from a national Data Protection Commissioner or his/her >>> > office (or from a internationally recognized body of national Data >>> > Protection Commissioners in a certain region of the world, including >>> > the Article 29 Working Party that analyzes the national data >>> > protection and privacy laws) that ICANN's contractual obligations for >>> > Registry and/or Registrar contracts violate the data protection laws >>> > of their country or their group of countries; >>> > >>> > -Evidence of legal and/or jurisdictional conflict arising from >>> > analysis performed by ICANN's legal department or by national legal >>> > experts hired by ICANN to evaluate the Whois requirements of the ICANN >>> > contracts for compliance and conflicts with national data protection >>> > laws and cross-border transfer limits) (similar to the process we >>> > understand was undertaken for the data retention issue); >>> > >>> > -Receipt of a written legal opinion from a nationally recognized law >>> > firm or qualified legal practitioner in the applicable jurisdiction >>> > that states that the collection, retention and/or transfer of certain >>> > Whois data elements as required by Registrar or Registry Agreements is >>> > ?reasonably likely to violate the applicable law? of the Registry or >>> > Registrar (per the process allowed in RAA Data Retention >>> > Specification); or >>> > >>> > -An official opinion of any other governmental body of competent >>> > jurisdiction providing that compliance with the data protection >>> > requirements of the Registry/Registrar contracts violates applicable >>> > national law (although such pro-active opinions may not be the >>> > practice of the Data Protection Commissioner's office). >>> > >>> > The above list draws from the comments of the European Commission, >>> > Data Retention Specification of the 2013Registrar Accreditation >>> > Agreement, and sound compliance and business practices for the ICANN >>> > General Counsel's office. >>> > >>> > We further agree with Blacknight that the requirements for triggering >>> > any review and consideration by ICANN be: simple and straightforward, >>> > quick and easy to access. >>> > >>> > 1.3Are there any components of the triggering event/notification >>> > portion of the RAA's Data Retention waiver process that should be >>> > considered as optional for incorporation into a modified Whois >>> Procedure? >>> > >>> > 1.3 Response:Absolutely, the full list in 1.1a above, together with >>> > other constructive contributions in the Comments and Reply Comments of >>> > this proceeding, should be strongly considered for incorporation into >>> > a modified Whois Procedure, or simply written into the contracts of >>> > the Registries and Registrars contractual language, or a new Annex or >>> > Specification. >>> > >>> > We respectfully submit that the obligation of Registries and >>> > Registrars to comply with their national laws is not a matter of >>> > multistakeholder decision making, but a matter of law and compliance. >>> > In this case, we wholeheartedly embrace the concept of building a >>> > process together that will allow exceptions for data protection and >>> > privacy laws to be adopted quickly and easily. >>> > >>> > 1.4Should parties be permitted to invoke the Whois Procedure before >>> > contracting with ICANN as a registrar or registry? >>> > >>> > 1.4 Response: Of course, Registries and Registrars should be allowed >>> > to invoke the Whois Procedure, or other appropriate annexes and >>> > specifications that may be added into Registry and Registrar contracts >>> > with ICANN. As discussed above, the right of a legal company to enter >>> > into a legal contracts is the most basic of expectations under law. >>> > >>> > 2.1Are there other relevant parties who should be included in this >>> step? >>> > >>> > 2.1 Response: We agree with the EC that ICANN should be working as >>> > closely with National Data Protection Authorities as they will allow. >>> > In light of the overflow of work into these national commissions, and >>> > the availability of national experts at law firms, ICANN should also >>> > turn to the advice of private experts,such as well-respected law firms >>> > who specialize in national data protection laws. The law firm's >>> > opinions on these matters would help to guide ICANN's knowledge and >>> > evaluation of this important issue. >>> > >>> > 3.1How is an agreement reached and published? >>> > >>> > 3.1 Response. As discussed above, compliance with national law may not >>> > be the best matter for negotiation within a multistakeholder process. >>> > It really should not be a chose for others to make whether you comply >>> > with your national data protection and privacy laws. That said, the >>> > process of refining the Consensus Procedure, and adopting new policies >>> > and procedures, or simply putting new contract provisions, annexes or >>> > specifications into the Registry and Registrar contracts SHOULD be >>> > subject to community discussion, notification and review.But once the >>> > new process is adopted, we think the new changes, variations, >>> > modifications or exceptions of Individual Registries and Registrars >>> > need go through a public review and process. The results, however, >>> > Should be published for Community notification and review. >>> > >>> > We note that in conducting the discussion with the Community on the >>> > overall or general procedure, policy or contractual changes, ICANN >>> > should be assertive in its outreach to the Data Protection >>> > Commissioners. Individual and through their organizations, they have >>> > offered to help ICANN evaluate this issue numerous times. The Whois >>> > Review Team noted the inability of many external bodies to monitor >>> > ICANN regularly, but the need for outreach to them by ICANN staff >>> > nonetheless: >>> > >>> > *Recommendation 3:Outreach* >>> > >>> > *ICANN should ensure that WHOIS policy issues are accompanied by >>> > cross-community outreach, including outreach to the communities >>> > outside of ICANN with a specific interest in the issues, and an >>> > ongoing program for consumer awareness. (Whois Review Team Final >>> Report)* >>> > >>> > This is a critical policy item for such outreach and input. >>> > >>> > 3.2If there is an agreed outcome among the relevant parties, should >>> > the Board be involved in this procedure? >>> > >>> > 3.2 Response: Clearly, the changing of the procedure, or the adoption >>> > of a new policy or new contractual language for Registries and >>> > Registrars, Board oversight and review should be involved. But once >>> > the new procedure, policy or contractual language is in place, then >>> > subsequent individual changes, variations, modifications or exceptions >>> > should be handled through the process and ICANN Staff ? as the Data >>> > Retention Process is handled today. >>> > >>> > 4.1Would it be fruitful to incorporate public comment in each of the >>> > resolution scenarios. >>> > >>> > 4.1 Response: We think this question means whether there should be >>> > public input on each and every exception?We respectfully submit that >>> > the answer is No. Once the new policy, procedure or contractual >>> > language is adopted, then the process should kick in and the >>> > Registrar/Registry should be allowed to apply for the waiver, >>> > modification or revision consistent with its data protection and >>> > privacy laws.Of course, once the waiver or modification is granted, >>> > the decision should be matter of public record so that other >>> > Registries and Registrars in the jurisdiction know and so that the >>> > ICANN Community as a whole can monitor this process' implementation >>> > and compliance. >>> > >>> > Step Five: Public notice >>> > >>> > 5.2Is the exemption or modification termed to the length of the >>> > agreement? Or is it indefinite as long as the contracted party is >>> > located in the jurisdiction in question, or so long as the applicable >>> > law is in force. >>> > >>> > 5.2 Response:We agree with the European Commission in its response, >>> > >>> > ?/By logic the exemption or modification shall be in place as long as >>> > the party is subject to the jurisdiction in conflict with ICANN rules. >>> > If the applicable law was to change, or the contacted party moved to a >>> > different jurisdiction, the conditions should be reviewed to assess if >>> > the exemption is still justified.?/ >>> > >>> > // >>> > >>> > But provided it is the same parties, operating under the same laws, >>> > the modification or change should continue through the duration of the >>> > relationship between the Registry/Registrar and ICANN. >>> > >>> > 5.3Should an exemption or modification based on the same laws and >>> > facts then be granted to other affected contracted parties in the same >>> > jurisdiction without invoking the Whois Procedure. >>> > >>> > 5.3 Response. The European Commission in its comments wrote, and we >>> > strongly agree: /?the same exception should apply to others in the >>> > same jurisdiction who can demonstrate that they are in the same >>> > situation.? /Further, Blacknight wrote and we support: /?if ANY >>> > registrar in Germany, for example, is granted a waiver based on German >>> > law, than ALL registrars based in Germany should receive the same >>> > treatment.? /Once a national data protection or privacy law is >>> > interpreted as requiring and exemption or modification, it should be >>> > available to all Registries/Registrars in that country. >>> > >>> > Further, we recommend that ICANN should be required to notify each >>> > gTLD Registry and Registrar in the same jurisdiction as that of the >>> > decision so they will have notice of the change. >>> > >>> > We thank ICANN staff for holding this comment period. >>> > >>> > Respectfully submitted, >>> > >>> > Rafik Dammak >>> > >>> > Chairman, NCSG >>> > >>> > On behalf of the Noncommercial Stakeholders Group >>> > >>> > >>> > >>> >>> >>> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.farrell Sat Aug 2 12:37:44 2014 From: maria.farrell (Maria Farrell) Date: Sat, 2 Aug 2014 10:37:44 +0100 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: Hi Rafik, Yes, these comments have achieved consensus and can be submitted on behalf of ncsg. Cheers, m Sent from my iPhone > On 1 Aug 2014, at 19:34, Rafik Dammak wrote: > > Hi Maria, > > thank you, I think we already passed the deadline for comment, can we consider that the comments are endorsed and ready to be submitted? > > Best, > > Rafik > > > 2014-08-01 20:27 GMT+09:00 Maria Farrell : >> My apologies, I made the call for consensus on the next-to-final draft. >> >> Draft 6, what should be the final draft, closes for comments at 1500 UTC today. >> >> Speak now or hold your peace, colleagues. >> >> All the best, Maria >> >> >>> On 1 August 2014 12:20, Rafik Dammak wrote: >>> Thanks Stephanie for the edits and merging the comments. >>> @Maria can you please make the call for consensus. I think Avri agrees with the changes but she will confirm that. >>> we have less than 12 hours to submit the comments. >>> >>> Rafik >>> >>> 2014-08-01 19:24 GMT+09:00 Stephanie Perrin : >>> >>>> Thanks for sending, I am having trouble with attachments but I got it. I think I have made all the corrections now, here is the amended version 6, I believe you can post it. >>>> cheers Stephanie >>>> >>>>> On 2014-08-01, 6:11, Rafik Dammak wrote: >>>>> Hi Stephanie, >>>>> >>>>> I think joy included her language in the attached document, can you please merge that with the latest draft you circulated? >>>>> Lesson learned: using a shared online document and avoid the word document versioning nightmare. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "joy" >>>>> Date: Jul 31, 2014 3:05 AM >>>>> Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding >>>>> To: >>>>> Cc: >>>>> >>>>> Hi - thanks everyone for the effort on this >>>>> I have also added some information on the recent report of the UN High >>>>> Commissioner for Human Rights on the right to privacy in the digital age >>>>> - which includes aspects relevant for companies - plus one or two other >>>>> minor comments >>>>> Hope you get these in time! >>>>> Joy >>>>> >>>>> On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: >>>>> > Hi All, >>>>> > Attached is the revised version of the comments. It has the changes of >>>>> > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's >>>>> > signature and submission on behalf of the NCSG (feel free to add an >>>>> > electronic signature, Rafik!). (Track changes version showing edits >>>>> > attached) >>>>> > >>>>> > If you could please use _this version _of the revised comments for >>>>> > review and submission, that would be great. >>>>> > Best, >>>>> > Kathy >>>>> > >>>>> > >>>>> > ----------------------------------------------------------------------------------------------------------------------------------------------- >>>>> > >>>>> > NCSG Response to the Questions of the >>>>> > >>>>> > /Review of the ICANN Procedure for Handling WHOIS Conflicts with >>>>> > Privacy Law / >>>>> > >>>>> > https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// >>>>> > >>>>> > >>>>> > ** >>>>> > >>>>> > The Noncommercial Stakeholders Group represents noncommercial >>>>> > organizations and individual noncommercial users in their work in the >>>>> > policy and proceedings of ICANN and the GNSO. We respectfully submit >>>>> > as an opening premise that every legal business has the right and >>>>> > obligation to operate within the bounds and limits of its national >>>>> > laws and regulations. No legal business establishes itself to violate >>>>> > the law; and to do so is an invitation to civil and criminal >>>>> > penalties, in addition to reputational damage and a loss of the trust >>>>> > of their customers and business partner. ICANN Registries and >>>>> > Registrars are no different ? they want and need to abide by their laws. >>>>> > >>>>> > To that end, Registries and Registrars strive to comply with their >>>>> > national and local laws.They strive affirmatively and proactively to >>>>> > follow the laws and regulations under which they operate as legal >>>>> > entities. To do otherwise is to violate the purpose of a legal regime, >>>>> > to threaten the well being of the company, and to expose Directors, >>>>> > Officers and Employees to fines, jail, or civil litigation. In the >>>>> > matter of protection of personal and confidential information, which >>>>> > is a very newsworthy issue in the 21^st century, privacy practices are >>>>> > a matter of consumer trust, and therefore high risk for those >>>>> > operating an Internet business.Even if customers have obediently >>>>> > complied with demands for excessive collection and disclosure of >>>>> > personal information up to this point, in the current news furor over >>>>> > Snowden and the cooperation of business with national governments >>>>> > engaged in surveillance, this could change with the next news >>>>> > story.The Internet facilitates successful privacy campaigns. >>>>> > >>>>> > Thus, it is wise and timely for ICANN to raise the questions of this >>>>> > proceeding, /Review of the ICANN Procedure for Handling WHOIS >>>>> > Conflicts with Privacy Law/ (albeit at a busy time for the Community >>>>> > and at the height of summer; we expect to see more interest in this >>>>> > time towards the Fall and recommend that ICANN not construe the small >>>>> > number of comments received to date as a reflection of lack of >>>>> > interest). We submit these comments in response to the issues raises >>>>> > and the questions asked. >>>>> > >>>>> > *Background* >>>>> > >>>>> > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law >>>>> > /was adopted in 2006 after years of debate on Whois issues. This >>>>> > Consensus Procedure was the first step of recognition that data >>>>> > protection laws and privacy law DO apply to the personal and sensitive >>>>> > data being collected by Registries and Registrars for the Whois database. >>>>> > >>>>> > But for those of us in the Noncommercial Users Constituency (now part >>>>> > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft >>>>> > and adopt this Consensus Procedure in the mid-2000s, we were always >>>>> > shocked that the ICANN Community did not do more. At the time, several >>>>> > Whois Task Forces were at work with multiple proposals which include >>>>> > important and pro-active suggestions to allow Registrars and >>>>> > Registries to come into compliance with their national and local data >>>>> > protection and privacy laws. >>>>> > >>>>> > At the time, we never expected this Consensus Procedure to be an end >>>>> > itself ? but the first of many steps. We are glad the discussion is >>>>> > now reopened and we support empowering Registrars and Registries to be >>>>> > in full compliance with their national and local data protection, >>>>> > consumer protection and privacy laws ? from the moment they enter into >>>>> > their contracts with ICANN. >>>>> > >>>>> > We note there have been a number of recent decisions in higher courts >>>>> > in various jurisdictions which impact the constitutional rights of >>>>> > citizens to be free from warrantless disclosure and retention of their >>>>> > personal information for law enforcement purposes.This reflects the >>>>> > time it takes for data protection issues to wend their way to the high >>>>> > courts for a ruling.We would urge ICANN, who otherwise sit on the >>>>> > cutting edge of Internet technical issues, to reflect on their role as >>>>> > a key global player in Internet governance.Do we lead or do we wait >>>>> > until we are dragged into Court, to realize our responsibilities to >>>>> > protect the fundamental rights of the citizens who depend on the >>>>> > Internet to participate in modern society?// >>>>> > >>>>> > II. Data Protection and Privacy Laws ? A Quick Overview of the >>>>> > Principles that Protect the Personal and Sensitive Data of Individuals >>>>> > and Organizations/Small Businesses >>>>> > >>>>> > It is important to stress that while the discourse about data >>>>> > protection requirements at ICANN has tended to focus on the European >>>>> > Union and its Data Commissioners, as represented in the Article 29 >>>>> > Working Party on Data Protection, there are a great many countries >>>>> > which have data protection law in place, including Canada, Mexico, >>>>> > much of South America, Korea, Japan, Australia, New Zealand, >>>>> > Singapore, South Africa, and many others.It is therefore quite >>>>> > puzzling that ICANN does not assemble a working group to study the >>>>> > matter and develop a harmonized approach to the issue, rather than >>>>> > take this rather odd approach of forcing registrars and registries to >>>>> > break national and local law. >>>>> > >>>>> > It is also important to note that there are many levels of data >>>>> > protection law, from local municipal law to state and national >>>>> > law.There is also sectoral law which applies to certain sectors.It >>>>> > would be a reasonable approach to develop a policy that reflects >>>>> > harmonized best practice, and abide by the policy rather than engage >>>>> > in this adversarial approach to local law.Data protection law is >>>>> > overwhelmingly complaints based, so it is inherently difficult for >>>>> > registrars and registries to get a ruling from data protection >>>>> > commissioners absent a complaint and a set of facts. >>>>> > >>>>> > In this regard, we also find it puzzling that despite the fact that >>>>> > the Article 29 Working Party wrote to ICANN senior management to >>>>> > indicate that they have reviewed the matter and reached an opinion >>>>> > that the practices involving WHOIS do indeed violate EU law, ICANN has >>>>> > not taken that message and developed a policy that guides their data >>>>> > protection practices, starting with a clear statement of limited >>>>> > purpose for the collection, use, and disclosure of personal information. >>>>> > >>>>> > The NCSG held a privacy meeting at the London ICANN 50 meeting, which >>>>> > was quite well attended.While we did not specifically address or >>>>> > attempt to brainstorm this particular problem, we feel it is safe to >>>>> > summarize the following points: >>>>> > >>>>> > ?There is considerable interest, in civil society, in the protection >>>>> > of personal information at ICANN. >>>>> > >>>>> > ?Policies and procedures such as were developed for the 2013 RAA are >>>>> > very puzzling to those who are engaged in government and business in >>>>> > the privacy field.This is not 1995, when the EU Directive on data >>>>> > protection was passed and was still controversial.ICANN needs to catch >>>>> > up with global business practice, preferably by developing binding >>>>> > corporate rules which would take a harmonized approach to the >>>>> > differing local laws. It is not appropriate for all data protection to >>>>> > fall away in jurisdictions where there is not yet a data protection >>>>> > law that applies to the provision of internet services, including >>>>> > domain name registration. >>>>> > >>>>> > ?NCSG is ramping up a team of volunteers to provide more detailed >>>>> > expertise and input on a number of privacy and free speech >>>>> > issues.While civil society is inherently stretched and short of >>>>> > resources, this is an issue that they care deeply about, and our >>>>> > outreach has begun to bear fruit in engaging others who are outside >>>>> > the immediate sphere of ICANN membership.This is important as they are >>>>> > part of the constituency we seek to represent. >>>>> > >>>>> > ICANN spends considerable time on technical parameters, data accuracy, >>>>> > and retention.More time needs to be spent on data protection policy.In >>>>> > this respect, more expertise would be required as there is very little >>>>> > evidence of privacy expertise in the ICANN community. >>>>> > >>>>> > III*/./*Questions asked of the Community in this Proceeding >>>>> > >>>>> > The ICANN Review Paper raised a number of excellent questions. In >>>>> > keeping with the requirements of a Reply Period, these NCSG comments >>>>> > will address both our comments and those comments we particularly >>>>> > support in this proceeding. >>>>> > >>>>> > However we would first like to note that the paper appears to start >>>>> > from the position that the procedures involved in this waiver process >>>>> > simply need to be tweaked.Operating under the first principle that all >>>>> > business must comply with local law, there is a need for ICANN to >>>>> > embrace data protection law as a well recognized branch of law which >>>>> > codifies well recognized business best practices with respect to the >>>>> > confidentiality of customer data.We respectfully submit that, if ICANN >>>>> > had a professional privacy officer, it is highly unlikely that he/she >>>>> > would recommend to senior management that the current approach be >>>>> > entertained in 2014. >>>>> > >>>>> > 1.1Is it impractical for ICANN to require that a contracted party >>>>> > already haslitigation or a government proceeding initiated against it >>>>> > prior to being able to invoke the Whois Procedure? >>>>> > >>>>> > 1.1 Response: Yes, it is completely impractical (and ill-advised) to >>>>> > force a company to violate a national law as a condition of complying >>>>> > with their contract. Every lawyer advises businesses to comply with >>>>> > the laws and regulations of their field. To do otherwise is to face >>>>> > fines, penalties, loss of the business, even jail for officers and >>>>> > directors. Legal business strives to be law-abiding; no officer or >>>>> > director wants to go to jail for her company's violations. It is the >>>>> > essence of an attorney's advice to his/her clients to fully comply >>>>> > with the laws and operate clearly within the clear boundaries and >>>>> > limits of laws and regulations, both national, by province or state >>>>> > and local. >>>>> > >>>>> > In these Reply Comments, we support and encourage ICANN to adopt >>>>> > policies consistent with the initial comments submitted by the >>>>> > European Commission: >>>>> > >>>>> > -that the Whois Procedure be changed from requiring specific >>>>> > prosecutorial action instead to allowing ?demonstrating evidence of a >>>>> > potential conflict widely and e.g. accepting information on the >>>>> > legislation imposing requirements that the contractual requirements >>>>> > would breach as sufficient evidence.? (European Commission comments) >>>>> > >>>>> > We also agree with Blacknight: >>>>> > >>>>> > -?It's completely illogical for ICANN to require that a contracting >>>>> > party already has litigation before they can use a process. We would >>>>> > have loved to use a procedure or process to get exemptions, but >>>>> > expecting us to already be litigating before we can do so is, for lack >>>>> > of a better word, nuts.? (Blacknight comments in this proceeding). >>>>> > >>>>> > - >>>>> > >>>>> > 1.1a How can the triggering event be meaningfully defined? >>>>> > >>>>> > This is an important question. Rephrased, we might ask together ?what >>>>> > must a Registry or Registrar show ICANN in support of its claim that >>>>> > certain provisions involving Whois data violate provisions of national >>>>> > data protection and privacy laws? >>>>> > >>>>> > NCSG respectfully submits that there are at least four ?triggering >>>>> > events? that ICANN should recognize: >>>>> > >>>>> > -Evidence from a national Data Protection Commissioner or his/her >>>>> > office (or from a internationally recognized body of national Data >>>>> > Protection Commissioners in a certain region of the world, including >>>>> > the Article 29 Working Party that analyzes the national data >>>>> > protection and privacy laws) that ICANN's contractual obligations for >>>>> > Registry and/or Registrar contracts violate the data protection laws >>>>> > of their country or their group of countries; >>>>> > >>>>> > -Evidence of legal and/or jurisdictional conflict arising from >>>>> > analysis performed by ICANN's legal department or by national legal >>>>> > experts hired by ICANN to evaluate the Whois requirements of the ICANN >>>>> > contracts for compliance and conflicts with national data protection >>>>> > laws and cross-border transfer limits) (similar to the process we >>>>> > understand was undertaken for the data retention issue); >>>>> > >>>>> > -Receipt of a written legal opinion from a nationally recognized law >>>>> > firm or qualified legal practitioner in the applicable jurisdiction >>>>> > that states that the collection, retention and/or transfer of certain >>>>> > Whois data elements as required by Registrar or Registry Agreements is >>>>> > ?reasonably likely to violate the applicable law? of the Registry or >>>>> > Registrar (per the process allowed in RAA Data Retention >>>>> > Specification); or >>>>> > >>>>> > -An official opinion of any other governmental body of competent >>>>> > jurisdiction providing that compliance with the data protection >>>>> > requirements of the Registry/Registrar contracts violates applicable >>>>> > national law (although such pro-active opinions may not be the >>>>> > practice of the Data Protection Commissioner's office). >>>>> > >>>>> > The above list draws from the comments of the European Commission, >>>>> > Data Retention Specification of the 2013Registrar Accreditation >>>>> > Agreement, and sound compliance and business practices for the ICANN >>>>> > General Counsel's office. >>>>> > >>>>> > We further agree with Blacknight that the requirements for triggering >>>>> > any review and consideration by ICANN be: simple and straightforward, >>>>> > quick and easy to access. >>>>> > >>>>> > 1.3Are there any components of the triggering event/notification >>>>> > portion of the RAA's Data Retention waiver process that should be >>>>> > considered as optional for incorporation into a modified Whois Procedure? >>>>> > >>>>> > 1.3 Response:Absolutely, the full list in 1.1a above, together with >>>>> > other constructive contributions in the Comments and Reply Comments of >>>>> > this proceeding, should be strongly considered for incorporation into >>>>> > a modified Whois Procedure, or simply written into the contracts of >>>>> > the Registries and Registrars contractual language, or a new Annex or >>>>> > Specification. >>>>> > >>>>> > We respectfully submit that the obligation of Registries and >>>>> > Registrars to comply with their national laws is not a matter of >>>>> > multistakeholder decision making, but a matter of law and compliance. >>>>> > In this case, we wholeheartedly embrace the concept of building a >>>>> > process together that will allow exceptions for data protection and >>>>> > privacy laws to be adopted quickly and easily. >>>>> > >>>>> > 1.4Should parties be permitted to invoke the Whois Procedure before >>>>> > contracting with ICANN as a registrar or registry? >>>>> > >>>>> > 1.4 Response: Of course, Registries and Registrars should be allowed >>>>> > to invoke the Whois Procedure, or other appropriate annexes and >>>>> > specifications that may be added into Registry and Registrar contracts >>>>> > with ICANN. As discussed above, the right of a legal company to enter >>>>> > into a legal contracts is the most basic of expectations under law. >>>>> > >>>>> > 2.1Are there other relevant parties who should be included in this step? >>>>> > >>>>> > 2.1 Response: We agree with the EC that ICANN should be working as >>>>> > closely with National Data Protection Authorities as they will allow. >>>>> > In light of the overflow of work into these national commissions, and >>>>> > the availability of national experts at law firms, ICANN should also >>>>> > turn to the advice of private experts,such as well-respected law firms >>>>> > who specialize in national data protection laws. The law firm's >>>>> > opinions on these matters would help to guide ICANN's knowledge and >>>>> > evaluation of this important issue. >>>>> > >>>>> > 3.1How is an agreement reached and published? >>>>> > >>>>> > 3.1 Response. As discussed above, compliance with national law may not >>>>> > be the best matter for negotiation within a multistakeholder process. >>>>> > It really should not be a chose for others to make whether you comply >>>>> > with your national data protection and privacy laws. That said, the >>>>> > process of refining the Consensus Procedure, and adopting new policies >>>>> > and procedures, or simply putting new contract provisions, annexes or >>>>> > specifications into the Registry and Registrar contracts SHOULD be >>>>> > subject to community discussion, notification and review.But once the >>>>> > new process is adopted, we think the new changes, variations, >>>>> > modifications or exceptions of Individual Registries and Registrars >>>>> > need go through a public review and process. The results, however, >>>>> > Should be published for Community notification and review. >>>>> > >>>>> > We note that in conducting the discussion with the Community on the >>>>> > overall or general procedure, policy or contractual changes, ICANN >>>>> > should be assertive in its outreach to the Data Protection >>>>> > Commissioners. Individual and through their organizations, they have >>>>> > offered to help ICANN evaluate this issue numerous times. The Whois >>>>> > Review Team noted the inability of many external bodies to monitor >>>>> > ICANN regularly, but the need for outreach to them by ICANN staff >>>>> > nonetheless: >>>>> > >>>>> > *Recommendation 3:Outreach* >>>>> > >>>>> > *ICANN should ensure that WHOIS policy issues are accompanied by >>>>> > cross-community outreach, including outreach to the communities >>>>> > outside of ICANN with a specific interest in the issues, and an >>>>> > ongoing program for consumer awareness. (Whois Review Team Final Report)* >>>>> > >>>>> > This is a critical policy item for such outreach and input. >>>>> > >>>>> > 3.2If there is an agreed outcome among the relevant parties, should >>>>> > the Board be involved in this procedure? >>>>> > >>>>> > 3.2 Response: Clearly, the changing of the procedure, or the adoption >>>>> > of a new policy or new contractual language for Registries and >>>>> > Registrars, Board oversight and review should be involved. But once >>>>> > the new procedure, policy or contractual language is in place, then >>>>> > subsequent individual changes, variations, modifications or exceptions >>>>> > should be handled through the process and ICANN Staff ? as the Data >>>>> > Retention Process is handled today. >>>>> > >>>>> > 4.1Would it be fruitful to incorporate public comment in each of the >>>>> > resolution scenarios. >>>>> > >>>>> > 4.1 Response: We think this question means whether there should be >>>>> > public input on each and every exception?We respectfully submit that >>>>> > the answer is No. Once the new policy, procedure or contractual >>>>> > language is adopted, then the process should kick in and the >>>>> > Registrar/Registry should be allowed to apply for the waiver, >>>>> > modification or revision consistent with its data protection and >>>>> > privacy laws.Of course, once the waiver or modification is granted, >>>>> > the decision should be matter of public record so that other >>>>> > Registries and Registrars in the jurisdiction know and so that the >>>>> > ICANN Community as a whole can monitor this process' implementation >>>>> > and compliance. >>>>> > >>>>> > Step Five: Public notice >>>>> > >>>>> > 5.2Is the exemption or modification termed to the length of the >>>>> > agreement? Or is it indefinite as long as the contracted party is >>>>> > located in the jurisdiction in question, or so long as the applicable >>>>> > law is in force. >>>>> > >>>>> > 5.2 Response:We agree with the European Commission in its response, >>>>> > >>>>> > ?/By logic the exemption or modification shall be in place as long as >>>>> > the party is subject to the jurisdiction in conflict with ICANN rules. >>>>> > If the applicable law was to change, or the contacted party moved to a >>>>> > different jurisdiction, the conditions should be reviewed to assess if >>>>> > the exemption is still justified.?/ >>>>> > >>>>> > // >>>>> > >>>>> > But provided it is the same parties, operating under the same laws, >>>>> > the modification or change should continue through the duration of the >>>>> > relationship between the Registry/Registrar and ICANN. >>>>> > >>>>> > 5.3Should an exemption or modification based on the same laws and >>>>> > facts then be granted to other affected contracted parties in the same >>>>> > jurisdiction without invoking the Whois Procedure. >>>>> > >>>>> > 5.3 Response. The European Commission in its comments wrote, and we >>>>> > strongly agree: /?the same exception should apply to others in the >>>>> > same jurisdiction who can demonstrate that they are in the same >>>>> > situation.? /Further, Blacknight wrote and we support: /?if ANY >>>>> > registrar in Germany, for example, is granted a waiver based on German >>>>> > law, than ALL registrars based in Germany should receive the same >>>>> > treatment.? /Once a national data protection or privacy law is >>>>> > interpreted as requiring and exemption or modification, it should be >>>>> > available to all Registries/Registrars in that country. >>>>> > >>>>> > Further, we recommend that ICANN should be required to notify each >>>>> > gTLD Registry and Registrar in the same jurisdiction as that of the >>>>> > decision so they will have notice of the change. >>>>> > >>>>> > We thank ICANN staff for holding this comment period. >>>>> > >>>>> > Respectfully submitted, >>>>> > >>>>> > Rafik Dammak >>>>> > >>>>> > Chairman, NCSG >>>>> > >>>>> > On behalf of the Noncommercial Stakeholders Group >>>>> > >>>>> > >>>>> > >>>>> >>>> >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Mon Aug 4 15:05:43 2014 From: rafik.dammak (Rafik Dammak) Date: Mon, 4 Aug 2014 21:05:43 +0900 Subject: [PC-NCSG] Fwd: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding In-Reply-To: References: <53D7DD8C.9030307@kathykleiman.com> <53D90DA7.60102@kathykleiman.com> <29D3E3FE-E251-4989-AB02-1C1ADED24496@ipjustice.org> <53D91AB4.6050702@kathykleiman.com> <53D9A416.4000907@apc.org> <53DB6AE6.8040008@mail.utoronto.ca> Message-ID: Hi Maria, Thank you for the confirmation, I submitted the comments in time last friday. thanks for everybody for the hardwork in such tight schedule Rafik 2014-08-02 18:37 GMT+09:00 Maria Farrell : > Hi Rafik, > > Yes, these comments have achieved consensus and can be submitted on behalf > of ncsg. > > Cheers, m > > Sent from my iPhone > > On 1 Aug 2014, at 19:34, Rafik Dammak wrote: > > Hi Maria, > > thank you, I think we already passed the deadline for comment, can we > consider that the comments are endorsed and ready to be submitted? > > Best, > > Rafik > > > 2014-08-01 20:27 GMT+09:00 Maria Farrell : > >> My apologies, I made the call for consensus on the next-to-final draft. >> >> Draft 6, what should be the final draft, closes for comments at 1500 UTC >> today. >> >> Speak now or hold your peace, colleagues. >> >> All the best, Maria >> >> >> On 1 August 2014 12:20, Rafik Dammak wrote: >> >>> Thanks Stephanie for the edits and merging the comments. >>> @Maria can you please make the call for consensus. I think Avri agrees >>> with the changes but she will confirm that. >>> we have less than 12 hours to submit the comments. >>> >>> Rafik >>> >>> 2014-08-01 19:24 GMT+09:00 Stephanie Perrin < >>> stephanie.perrin at mail.utoronto.ca>: >>> >>> Thanks for sending, I am having trouble with attachments but I got >>>> it. I think I have made all the corrections now, here is the amended >>>> version 6, I believe you can post it. >>>> cheers Stephanie >>>> >>>> On 2014-08-01, 6:11, Rafik Dammak wrote: >>>> >>>> Hi Stephanie, >>>> >>>> I think joy included her language in the attached document, can you >>>> please merge that with the latest draft you circulated? >>>> Lesson learned: using a shared online document and avoid the word >>>> document versioning nightmare. >>>> >>>> Best, >>>> >>>> Rafik >>>> ---------- Forwarded message ---------- >>>> From: "joy" >>>> Date: Jul 31, 2014 3:05 AM >>>> Subject: Re: [NCSG-Discuss] Draft Comments for Whois Proceeding >>>> To: >>>> Cc: >>>> >>>> Hi - thanks everyone for the effort on this >>>> I have also added some information on the recent report of the UN High >>>> Commissioner for Human Rights on the right to privacy in the digital age >>>> - which includes aspects relevant for companies - plus one or two other >>>> minor comments >>>> Hope you get these in time! >>>> Joy >>>> >>>> On 31/07/2014 4:17 a.m., Kathy Kleiman wrote: >>>> > Hi All, >>>> > Attached is the revised version of the comments. It has the changes of >>>> > Stephanie and Ed incorporated (tx you!) I have drafted it for Rafik's >>>> > signature and submission on behalf of the NCSG (feel free to add an >>>> > electronic signature, Rafik!). (Track changes version showing edits >>>> > attached) >>>> > >>>> > If you could please use _this version _of the revised comments for >>>> > review and submission, that would be great. >>>> > Best, >>>> > Kathy >>>> > >>>> > >>>> > >>>> ----------------------------------------------------------------------------------------------------------------------------------------------- >>>> > >>>> > NCSG Response to the Questions of the >>>> > >>>> > /Review of the ICANN Procedure for Handling WHOIS Conflicts with >>>> > Privacy Law / >>>> > >>>> > >>>> https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en// >>>> > >>>> > >>>> > ** >>>> > >>>> > The Noncommercial Stakeholders Group represents noncommercial >>>> > organizations and individual noncommercial users in their work in the >>>> > policy and proceedings of ICANN and the GNSO. We respectfully submit >>>> > as an opening premise that every legal business has the right and >>>> > obligation to operate within the bounds and limits of its national >>>> > laws and regulations. No legal business establishes itself to violate >>>> > the law; and to do so is an invitation to civil and criminal >>>> > penalties, in addition to reputational damage and a loss of the trust >>>> > of their customers and business partner. ICANN Registries and >>>> > Registrars are no different ? they want and need to abide by their >>>> laws. >>>> > >>>> > To that end, Registries and Registrars strive to comply with their >>>> > national and local laws.They strive affirmatively and proactively to >>>> > follow the laws and regulations under which they operate as legal >>>> > entities. To do otherwise is to violate the purpose of a legal regime, >>>> > to threaten the well being of the company, and to expose Directors, >>>> > Officers and Employees to fines, jail, or civil litigation. In the >>>> > matter of protection of personal and confidential information, which >>>> > is a very newsworthy issue in the 21^st century, privacy practices are >>>> > a matter of consumer trust, and therefore high risk for those >>>> > operating an Internet business.Even if customers have obediently >>>> > complied with demands for excessive collection and disclosure of >>>> > personal information up to this point, in the current news furor over >>>> > Snowden and the cooperation of business with national governments >>>> > engaged in surveillance, this could change with the next news >>>> > story.The Internet facilitates successful privacy campaigns. >>>> > >>>> > Thus, it is wise and timely for ICANN to raise the questions of this >>>> > proceeding, /Review of the ICANN Procedure for Handling WHOIS >>>> > Conflicts with Privacy Law/ (albeit at a busy time for the Community >>>> > and at the height of summer; we expect to see more interest in this >>>> > time towards the Fall and recommend that ICANN not construe the small >>>> > number of comments received to date as a reflection of lack of >>>> > interest). We submit these comments in response to the issues raises >>>> > and the questions asked. >>>> > >>>> > *Background* >>>> > >>>> > The /ICANN Procedure for Handling Whois Conflicts with Privacy Law >>>> > /was adopted in 2006 after years of debate on Whois issues. This >>>> > Consensus Procedure was the first step of recognition that data >>>> > protection laws and privacy law DO apply to the personal and sensitive >>>> > data being collected by Registries and Registrars for the Whois >>>> database. >>>> > >>>> > But for those of us in the Noncommercial Users Constituency (now part >>>> > of the Noncommercial Stakeholders Group/NCSG) who helped debate, draft >>>> > and adopt this Consensus Procedure in the mid-2000s, we were always >>>> > shocked that the ICANN Community did not do more. At the time, several >>>> > Whois Task Forces were at work with multiple proposals which include >>>> > important and pro-active suggestions to allow Registrars and >>>> > Registries to come into compliance with their national and local data >>>> > protection and privacy laws. >>>> > >>>> > At the time, we never expected this Consensus Procedure to be an end >>>> > itself ? but the first of many steps. We are glad the discussion is >>>> > now reopened and we support empowering Registrars and Registries to be >>>> > in full compliance with their national and local data protection, >>>> > consumer protection and privacy laws ? from the moment they enter into >>>> > their contracts with ICANN. >>>> > >>>> > We note there have been a number of recent decisions in higher courts >>>> > in various jurisdictions which impact the constitutional rights of >>>> > citizens to be free from warrantless disclosure and retention of their >>>> > personal information for law enforcement purposes.This reflects the >>>> > time it takes for data protection issues to wend their way to the high >>>> > courts for a ruling.We would urge ICANN, who otherwise sit on the >>>> > cutting edge of Internet technical issues, to reflect on their role as >>>> > a key global player in Internet governance.Do we lead or do we wait >>>> > until we are dragged into Court, to realize our responsibilities to >>>> > protect the fundamental rights of the citizens who depend on the >>>> > Internet to participate in modern society?// >>>> > >>>> > II. Data Protection and Privacy Laws ? A Quick Overview of the >>>> > Principles that Protect the Personal and Sensitive Data of Individuals >>>> > and Organizations/Small Businesses >>>> > >>>> > It is important to stress that while the discourse about data >>>> > protection requirements at ICANN has tended to focus on the European >>>> > Union and its Data Commissioners, as represented in the Article 29 >>>> > Working Party on Data Protection, there are a great many countries >>>> > which have data protection law in place, including Canada, Mexico, >>>> > much of South America, Korea, Japan, Australia, New Zealand, >>>> > Singapore, South Africa, and many others.It is therefore quite >>>> > puzzling that ICANN does not assemble a working group to study the >>>> > matter and develop a harmonized approach to the issue, rather than >>>> > take this rather odd approach of forcing registrars and registries to >>>> > break national and local law. >>>> > >>>> > It is also important to note that there are many levels of data >>>> > protection law, from local municipal law to state and national >>>> > law.There is also sectoral law which applies to certain sectors.It >>>> > would be a reasonable approach to develop a policy that reflects >>>> > harmonized best practice, and abide by the policy rather than engage >>>> > in this adversarial approach to local law.Data protection law is >>>> > overwhelmingly complaints based, so it is inherently difficult for >>>> > registrars and registries to get a ruling from data protection >>>> > commissioners absent a complaint and a set of facts. >>>> > >>>> > In this regard, we also find it puzzling that despite the fact that >>>> > the Article 29 Working Party wrote to ICANN senior management to >>>> > indicate that they have reviewed the matter and reached an opinion >>>> > that the practices involving WHOIS do indeed violate EU law, ICANN has >>>> > not taken that message and developed a policy that guides their data >>>> > protection practices, starting with a clear statement of limited >>>> > purpose for the collection, use, and disclosure of personal >>>> information. >>>> > >>>> > The NCSG held a privacy meeting at the London ICANN 50 meeting, which >>>> > was quite well attended.While we did not specifically address or >>>> > attempt to brainstorm this particular problem, we feel it is safe to >>>> > summarize the following points: >>>> > >>>> > ?There is considerable interest, in civil society, in the protection >>>> > of personal information at ICANN. >>>> > >>>> > ?Policies and procedures such as were developed for the 2013 RAA are >>>> > very puzzling to those who are engaged in government and business in >>>> > the privacy field.This is not 1995, when the EU Directive on data >>>> > protection was passed and was still controversial.ICANN needs to catch >>>> > up with global business practice, preferably by developing binding >>>> > corporate rules which would take a harmonized approach to the >>>> > differing local laws. It is not appropriate for all data protection to >>>> > fall away in jurisdictions where there is not yet a data protection >>>> > law that applies to the provision of internet services, including >>>> > domain name registration. >>>> > >>>> > ?NCSG is ramping up a team of volunteers to provide more detailed >>>> > expertise and input on a number of privacy and free speech >>>> > issues.While civil society is inherently stretched and short of >>>> > resources, this is an issue that they care deeply about, and our >>>> > outreach has begun to bear fruit in engaging others who are outside >>>> > the immediate sphere of ICANN membership.This is important as they are >>>> > part of the constituency we seek to represent. >>>> > >>>> > ICANN spends considerable time on technical parameters, data accuracy, >>>> > and retention.More time needs to be spent on data protection policy.In >>>> > this respect, more expertise would be required as there is very little >>>> > evidence of privacy expertise in the ICANN community. >>>> > >>>> > III*/./*Questions asked of the Community in this Proceeding >>>> > >>>> > The ICANN Review Paper raised a number of excellent questions. In >>>> > keeping with the requirements of a Reply Period, these NCSG comments >>>> > will address both our comments and those comments we particularly >>>> > support in this proceeding. >>>> > >>>> > However we would first like to note that the paper appears to start >>>> > from the position that the procedures involved in this waiver process >>>> > simply need to be tweaked.Operating under the first principle that all >>>> > business must comply with local law, there is a need for ICANN to >>>> > embrace data protection law as a well recognized branch of law which >>>> > codifies well recognized business best practices with respect to the >>>> > confidentiality of customer data.We respectfully submit that, if ICANN >>>> > had a professional privacy officer, it is highly unlikely that he/she >>>> > would recommend to senior management that the current approach be >>>> > entertained in 2014. >>>> > >>>> > 1.1Is it impractical for ICANN to require that a contracted party >>>> > already haslitigation or a government proceeding initiated against it >>>> > prior to being able to invoke the Whois Procedure? >>>> > >>>> > 1.1 Response: Yes, it is completely impractical (and ill-advised) to >>>> > force a company to violate a national law as a condition of complying >>>> > with their contract. Every lawyer advises businesses to comply with >>>> > the laws and regulations of their field. To do otherwise is to face >>>> > fines, penalties, loss of the business, even jail for officers and >>>> > directors. Legal business strives to be law-abiding; no officer or >>>> > director wants to go to jail for her company's violations. It is the >>>> > essence of an attorney's advice to his/her clients to fully comply >>>> > with the laws and operate clearly within the clear boundaries and >>>> > limits of laws and regulations, both national, by province or state >>>> > and local. >>>> > >>>> > In these Reply Comments, we support and encourage ICANN to adopt >>>> > policies consistent with the initial comments submitted by the >>>> > European Commission: >>>> > >>>> > -that the Whois Procedure be changed from requiring specific >>>> > prosecutorial action instead to allowing ?demonstrating evidence of a >>>> > potential conflict widely and e.g. accepting information on the >>>> > legislation imposing requirements that the contractual requirements >>>> > would breach as sufficient evidence.? (European Commission comments) >>>> > >>>> > We also agree with Blacknight: >>>> > >>>> > -?It's completely illogical for ICANN to require that a contracting >>>> > party already has litigation before they can use a process. We would >>>> > have loved to use a procedure or process to get exemptions, but >>>> > expecting us to already be litigating before we can do so is, for lack >>>> > of a better word, nuts.? (Blacknight comments in this proceeding). >>>> > >>>> > - >>>> > >>>> > 1.1a How can the triggering event be meaningfully defined? >>>> > >>>> > This is an important question. Rephrased, we might ask together ?what >>>> > must a Registry or Registrar show ICANN in support of its claim that >>>> > certain provisions involving Whois data violate provisions of national >>>> > data protection and privacy laws? >>>> > >>>> > NCSG respectfully submits that there are at least four ?triggering >>>> > events? that ICANN should recognize: >>>> > >>>> > -Evidence from a national Data Protection Commissioner or his/her >>>> > office (or from a internationally recognized body of national Data >>>> > Protection Commissioners in a certain region of the world, including >>>> > the Article 29 Working Party that analyzes the national data >>>> > protection and privacy laws) that ICANN's contractual obligations for >>>> > Registry and/or Registrar contracts violate the data protection laws >>>> > of their country or their group of countries; >>>> > >>>> > -Evidence of legal and/or jurisdictional conflict arising from >>>> > analysis performed by ICANN's legal department or by national legal >>>> > experts hired by ICANN to evaluate the Whois requirements of the ICANN >>>> > contracts for compliance and conflicts with national data protection >>>> > laws and cross-border transfer limits) (similar to the process we >>>> > understand was undertaken for the data retention issue); >>>> > >>>> > -Receipt of a written legal opinion from a nationally recognized law >>>> > firm or qualified legal practitioner in the applicable jurisdiction >>>> > that states that the collection, retention and/or transfer of certain >>>> > Whois data elements as required by Registrar or Registry Agreements is >>>> > ?reasonably likely to violate the applicable law? of the Registry or >>>> > Registrar (per the process allowed in RAA Data Retention >>>> > Specification); or >>>> > >>>> > -An official opinion of any other governmental body of competent >>>> > jurisdiction providing that compliance with the data protection >>>> > requirements of the Registry/Registrar contracts violates applicable >>>> > national law (although such pro-active opinions may not be the >>>> > practice of the Data Protection Commissioner's office). >>>> > >>>> > The above list draws from the comments of the European Commission, >>>> > Data Retention Specification of the 2013Registrar Accreditation >>>> > Agreement, and sound compliance and business practices for the ICANN >>>> > General Counsel's office. >>>> > >>>> > We further agree with Blacknight that the requirements for triggering >>>> > any review and consideration by ICANN be: simple and straightforward, >>>> > quick and easy to access. >>>> > >>>> > 1.3Are there any components of the triggering event/notification >>>> > portion of the RAA's Data Retention waiver process that should be >>>> > considered as optional for incorporation into a modified Whois >>>> Procedure? >>>> > >>>> > 1.3 Response:Absolutely, the full list in 1.1a above, together with >>>> > other constructive contributions in the Comments and Reply Comments of >>>> > this proceeding, should be strongly considered for incorporation into >>>> > a modified Whois Procedure, or simply written into the contracts of >>>> > the Registries and Registrars contractual language, or a new Annex or >>>> > Specification. >>>> > >>>> > We respectfully submit that the obligation of Registries and >>>> > Registrars to comply with their national laws is not a matter of >>>> > multistakeholder decision making, but a matter of law and compliance. >>>> > In this case, we wholeheartedly embrace the concept of building a >>>> > process together that will allow exceptions for data protection and >>>> > privacy laws to be adopted quickly and easily. >>>> > >>>> > 1.4Should parties be permitted to invoke the Whois Procedure before >>>> > contracting with ICANN as a registrar or registry? >>>> > >>>> > 1.4 Response: Of course, Registries and Registrars should be allowed >>>> > to invoke the Whois Procedure, or other appropriate annexes and >>>> > specifications that may be added into Registry and Registrar contracts >>>> > with ICANN. As discussed above, the right of a legal company to enter >>>> > into a legal contracts is the most basic of expectations under law. >>>> > >>>> > 2.1Are there other relevant parties who should be included in this >>>> step? >>>> > >>>> > 2.1 Response: We agree with the EC that ICANN should be working as >>>> > closely with National Data Protection Authorities as they will allow. >>>> > In light of the overflow of work into these national commissions, and >>>> > the availability of national experts at law firms, ICANN should also >>>> > turn to the advice of private experts,such as well-respected law firms >>>> > who specialize in national data protection laws. The law firm's >>>> > opinions on these matters would help to guide ICANN's knowledge and >>>> > evaluation of this important issue. >>>> > >>>> > 3.1How is an agreement reached and published? >>>> > >>>> > 3.1 Response. As discussed above, compliance with national law may not >>>> > be the best matter for negotiation within a multistakeholder process. >>>> > It really should not be a chose for others to make whether you comply >>>> > with your national data protection and privacy laws. That said, the >>>> > process of refining the Consensus Procedure, and adopting new policies >>>> > and procedures, or simply putting new contract provisions, annexes or >>>> > specifications into the Registry and Registrar contracts SHOULD be >>>> > subject to community discussion, notification and review.But once the >>>> > new process is adopted, we think the new changes, variations, >>>> > modifications or exceptions of Individual Registries and Registrars >>>> > need go through a public review and process. The results, however, >>>> > Should be published for Community notification and review. >>>> > >>>> > We note that in conducting the discussion with the Community on the >>>> > overall or general procedure, policy or contractual changes, ICANN >>>> > should be assertive in its outreach to the Data Protection >>>> > Commissioners. Individual and through their organizations, they have >>>> > offered to help ICANN evaluate this issue numerous times. The Whois >>>> > Review Team noted the inability of many external bodies to monitor >>>> > ICANN regularly, but the need for outreach to them by ICANN staff >>>> > nonetheless: >>>> > >>>> > *Recommendation 3:Outreach* >>>> > >>>> > *ICANN should ensure that WHOIS policy issues are accompanied by >>>> > cross-community outreach, including outreach to the communities >>>> > outside of ICANN with a specific interest in the issues, and an >>>> > ongoing program for consumer awareness. (Whois Review Team Final >>>> Report)* >>>> > >>>> > This is a critical policy item for such outreach and input. >>>> > >>>> > 3.2If there is an agreed outcome among the relevant parties, should >>>> > the Board be involved in this procedure? >>>> > >>>> > 3.2 Response: Clearly, the changing of the procedure, or the adoption >>>> > of a new policy or new contractual language for Registries and >>>> > Registrars, Board oversight and review should be involved. But once >>>> > the new procedure, policy or contractual language is in place, then >>>> > subsequent individual changes, variations, modifications or exceptions >>>> > should be handled through the process and ICANN Staff ? as the Data >>>> > Retention Process is handled today. >>>> > >>>> > 4.1Would it be fruitful to incorporate public comment in each of the >>>> > resolution scenarios. >>>> > >>>> > 4.1 Response: We think this question means whether there should be >>>> > public input on each and every exception?We respectfully submit that >>>> > the answer is No. Once the new policy, procedure or contractual >>>> > language is adopted, then the process should kick in and the >>>> > Registrar/Registry should be allowed to apply for the waiver, >>>> > modification or revision consistent with its data protection and >>>> > privacy laws.Of course, once the waiver or modification is granted, >>>> > the decision should be matter of public record so that other >>>> > Registries and Registrars in the jurisdiction know and so that the >>>> > ICANN Community as a whole can monitor this process' implementation >>>> > and compliance. >>>> > >>>> > Step Five: Public notice >>>> > >>>> > 5.2Is the exemption or modification termed to the length of the >>>> > agreement? Or is it indefinite as long as the contracted party is >>>> > located in the jurisdiction in question, or so long as the applicable >>>> > law is in force. >>>> > >>>> > 5.2 Response:We agree with the European Commission in its response, >>>> > >>>> > ?/By logic the exemption or modification shall be in place as long as >>>> > the party is subject to the jurisdiction in conflict with ICANN rules. >>>> > If the applicable law was to change, or the contacted party moved to a >>>> > different jurisdiction, the conditions should be reviewed to assess if >>>> > the exemption is still justified.?/ >>>> > >>>> > // >>>> > >>>> > But provided it is the same parties, operating under the same laws, >>>> > the modification or change should continue through the duration of the >>>> > relationship between the Registry/Registrar and ICANN. >>>> > >>>> > 5.3Should an exemption or modification based on the same laws and >>>> > facts then be granted to other affected contracted parties in the same >>>> > jurisdiction without invoking the Whois Procedure. >>>> > >>>> > 5.3 Response. The European Commission in its comments wrote, and we >>>> > strongly agree: /?the same exception should apply to others in the >>>> > same jurisdiction who can demonstrate that they are in the same >>>> > situation.? /Further, Blacknight wrote and we support: /?if ANY >>>> > registrar in Germany, for example, is granted a waiver based on German >>>> > law, than ALL registrars based in Germany should receive the same >>>> > treatment.? /Once a national data protection or privacy law is >>>> > interpreted as requiring and exemption or modification, it should be >>>> > available to all Registries/Registrars in that country. >>>> > >>>> > Further, we recommend that ICANN should be required to notify each >>>> > gTLD Registry and Registrar in the same jurisdiction as that of the >>>> > decision so they will have notice of the change. >>>> > >>>> > We thank ICANN staff for holding this comment period. >>>> > >>>> > Respectfully submitted, >>>> > >>>> > Rafik Dammak >>>> > >>>> > Chairman, NCSG >>>> > >>>> > On behalf of the Noncommercial Stakeholders Group >>>> > >>>> > >>>> > >>>> >>>> >>>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Thu Aug 7 03:34:27 2014 From: rafik.dammak (Rafik Dammak) Date: Thu, 7 Aug 2014 09:34:27 +0900 Subject: [PC-NCSG] Fwd: Results of the NCPH elections 2014 Message-ID: Hi everyone, please find below the result of the election. I am glad that we reached closure with satisfying result. the remaining point will be to fix for long-term the whole election process. Best, Rafik ---------- Forwarded message ---------- From: Glen de Saint G?ry Date: 2014-08-06 16:37 GMT+09:00 Subject: Results of the NCPH elections 2014 To: "gabrielaszlak at gmail.com" , " john at crediblecontext.com" , "tony holmes ( tonyarholmes at btinternet.com)" , "Novoa, Osvaldo" , "Winterfeldt, Brian J. ( brian.winterfeldt at kattenlaw.com)" , "Petter Rindforth (petter.rindforth at fenixlegal.eu) ( petter.rindforth at fenixlegal.eu)" , Maria Farrell , "Magaly Pazello (magaly.pazello at gmail.com)" , Klaus Stoll , "David Cake ( dave at difference.com.au) (dave at difference.com.au)" , Avri Doria , Amr Elsadr , "Reed, Daniel A (dan-reed at uiowa.edu)" Cc: "Metalitz, Steven" , Rafik Dammak Dear All, Below please find the results of the NCPH elections that closed on 5 August 2014 at 23:59 UTC. Markus Kummer 10 votes None of the above 3 votes Would you please check the machine results below to make sure that your vote was correctly registered. Please let me know if you have any questions. Thank you very much. Kind regards, Glen *Voting details:* 9 votes [] Markus Kummer + 1 vote received verbally because the person had no connectivity 3 votes [] None of the above *Ballots Received:* Ballot ID 5e00241c81c529f Received at 2014-07-31 12:26:18 UTC *(counted)* 1: [X] 2: [ ] Ballot ID cee2fda530742e9 Received at 2014-07-31 00:34:27 UTC *(counted)* 1: [X] 2: [ ] Ballot ID bf96966b5bbcd85 Received at 2014-07-30 17:19:55 UTC *(counted)* 1: [X] 2: [ ] Ballot ID 0c786b42367b77a Received at 2014-07-29 21:09:58 UTC *(counted)* 1: [X] 2: [ ] Ballot ID 1547ea714f31983 Received at 2014-07-29 20:49:53 UTC *(counted)* 1: [ ] 2: [X] Ballot ID 39597948471b461 Received at 2014-07-29 17:48:52 UTC *(counted)* 1: [X] 2: [ ] Ballot ID 39597948471b461 Received at 2014-07-29 17:48:33 UTC *(duplicate; not counted)* 1: [ ] 2: [ ] Ballot ID 71f2ea7ec07343c Received at 2014-07-29 13:55:33 UTC *(counted)* 1: [X] 2: [ ] Ballot ID ae9a8949f433cc9 Received at 2014-07-29 13:21:47 UTC *(counted)* 1: [ ] 2: [X] Ballot ID 76947c533d8f19a Received at 2014-07-29 12:59:34 UTC *(counted)* 1: [ ] 2: [X] Ballot ID 3f946c76159fe4a Received at 2014-07-29 11:16:06 UTC *(counted)* 1: [X] 2: [ ] Ballot ID 2631cd54dad7969 Received at 2014-07-29 09:42:23 UTC *(counted)* 1: [X] 2: [ ] Ballot ID 1050d8a0ecd868a Received at 2014-07-29 08:23:59 UTC *(counted)* 1: [X] 2: [ ] *List of Authorized Voters: * gabrielaszlak at gmail.com:1 john at crediblecontext.com:1 tonyarholmes at btinternet.com:1 onovoa at Antel.com.uy:1 brian.winterfeldt at kattenlaw.com:1 petter.rindforth at fenixlegal.eu:1 maria.farrell at gmail.com:1 magaly.pazello at gmail.com:1 kdrstoll at gmail.com:1 dave at difference.com.au:1 avri at acm.org:1 aelsadr at egyptig.org:1 dan-reed at uiowa.edu:1 *Email errors: *No email errors reported Glen de Saint G?ry GNSO Secretariat gnso.secretariat at gnso.icann.org http://gnso.icann.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Thu Aug 7 04:51:59 2014 From: avri (Avri Doria) Date: Wed, 06 Aug 2014 21:51:59 -0400 Subject: [PC-NCSG] Fwd: Results of the NCPH elections 2014 In-Reply-To: References: Message-ID: <53E2DBBF.6000800@acm.org> Hi, I am glad it came to closure. BTW, this may be the way we do it. We squabble of over people who aren't insiders until we find someone enough of us can agree on. avri On 06-Aug-14 20:34, Rafik Dammak wrote: > Hi everyone, > > please find below the result of the election. I am glad that we reached > closure with satisfying result. the remaining point will be to fix for > long-term the whole election process. > > Best, > > Rafik From wjdrake Thu Aug 7 09:08:47 2014 From: wjdrake (William Drake) Date: Thu, 7 Aug 2014 08:08:47 +0200 Subject: [PC-NCSG] Results of the NCPH elections 2014 In-Reply-To: References: Message-ID: Excellent news and to the extent bandwidth?s available let?s sensitize him to our issues and concerns, he?s very open to listening. BD On Aug 7, 2014, at 2:34 AM, Rafik Dammak wrote: > Hi everyone, > > please find below the result of the election. I am glad that we reached closure with satisfying result. the remaining point will be to fix for long-term the whole election process. > > Best, > > Rafik > > > ---------- Forwarded message ---------- > From: Glen de Saint G?ry > Date: 2014-08-06 16:37 GMT+09:00 > Subject: Results of the NCPH elections 2014 > To: "gabrielaszlak at gmail.com" , "john at crediblecontext.com" , "tony holmes (tonyarholmes at btinternet.com)" , "Novoa, Osvaldo" , "Winterfeldt, Brian J. (brian.winterfeldt at kattenlaw.com)" , "Petter Rindforth (petter.rindforth at fenixlegal.eu) (petter.rindforth at fenixlegal.eu)" , Maria Farrell , "Magaly Pazello (magaly.pazello at gmail.com)" , Klaus Stoll , "David Cake (dave at difference.com.au) (dave at difference.com.au)" , Avri Doria , Amr Elsadr , "Reed, Daniel A (dan-reed at uiowa.edu)" > Cc: "Metalitz, Steven" , Rafik Dammak > > > > > > > Dear All, > > > > Below please find the results of the NCPH elections that closed on 5 August 2014 at 23:59 UTC. > > > > Markus Kummer 10 votes > None of the above 3 votes > > > > Would you please check the machine results below to make sure that your vote was correctly registered. > Please let me know if you have any questions. > > Thank you very much. > > Kind regards, > > > > Glen > > > > > > Voting details: > > 9 votes [] Markus Kummer + 1 vote received verbally because the person had no connectivity > 3 votes [] None of the above > > > Ballots Received: > > > > Ballot ID 5e00241c81c529f Received at 2014-07-31 12:26:18 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID cee2fda530742e9 Received at 2014-07-31 00:34:27 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID bf96966b5bbcd85 Received at 2014-07-30 17:19:55 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID 0c786b42367b77a Received at 2014-07-29 21:09:58 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID 1547ea714f31983 Received at 2014-07-29 20:49:53 UTC (counted) > > 1: [ ] > > 2: [X] > > > > Ballot ID 39597948471b461 Received at 2014-07-29 17:48:52 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID 39597948471b461 Received at 2014-07-29 17:48:33 UTC (duplicate; not counted) > > 1: [ ] > > 2: [ ] > > > > Ballot ID 71f2ea7ec07343c Received at 2014-07-29 13:55:33 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID ae9a8949f433cc9 Received at 2014-07-29 13:21:47 UTC (counted) > > 1: [ ] > > 2: [X] > > > > Ballot ID 76947c533d8f19a Received at 2014-07-29 12:59:34 UTC (counted) > > 1: [ ] > > 2: [X] > > > > Ballot ID 3f946c76159fe4a Received at 2014-07-29 11:16:06 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID 2631cd54dad7969 Received at 2014-07-29 09:42:23 UTC (counted) > > 1: [X] > > 2: [ ] > > > > Ballot ID 1050d8a0ecd868a Received at 2014-07-29 08:23:59 UTC (counted) > > 1: [X] > > 2: [ ] > > > > List of Authorized Voters: > > gabrielaszlak at gmail.com:1 > > john at crediblecontext.com:1 > > tonyarholmes at btinternet.com:1 > > onovoa at Antel.com.uy:1 > > brian.winterfeldt at kattenlaw.com:1 > > petter.rindforth at fenixlegal.eu:1 > > maria.farrell at gmail.com:1 > > magaly.pazello at gmail.com:1 > > kdrstoll at gmail.com:1 > > dave at difference.com.au:1 > > avri at acm.org:1 > > aelsadr at egyptig.org:1 > > dan-reed at uiowa.edu:1 > > > > Email errors: No email errors reported > > > > > > Glen de Saint G?ry > GNSO Secretariat > > gnso.secretariat at gnso.icann.org > > http://gnso.icann.org > > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Fri Aug 8 16:13:49 2014 From: avri (Avri Doria) Date: Fri, 08 Aug 2014 09:13:49 -0400 Subject: [PC-NCSG] [NCSG-Discuss] Fairly Urgent: Possible Joint Statement on Accountability In-Reply-To: References: Message-ID: <53E4CD0D.5040206@acm.org> besides such decisions are made by the PC in NCSG. not by quick negotiation between the Leaders and not in a way that sidelines the council. still not in favor avri On 08-Aug-14 04:42, William Drake wrote: > Hi > > Further to the discussion about staff?s proposed accountability > mechanism, SG/constituency chairs have been discussing a possible joint > statement. As agreeing on details regarding specific concerns might take > some cycles and Fadi?s asked us to move quickly into alignment, Tony > Holmes of the ISPCP has circulated this place holder for collective > endorsement and rapid transmission. Would people be amenable to NCSG > signing onto this for now, with more to come? Bill > > /During ICANN meeting 50 the entire GNSO community came together to make > a statement calling for the Board to support community creation of an > independent accountability mechanism. That action clearly indicates the > importance of this issue to the community and its constituent groups. > Since then we have closely followed this issue and are now > considering //ICANN?s proposal for managing the accountability process. > However at this stage it would be both prudent and timely to advise you > that currently there is no alignment within the GNSO community on the > proposed approach or process proposed by ICANN. Discussions are on-going > and it is our intention to offer a more detailed statement of our > concerns as early as possible next week./ > / > / > Bill > > *********************************************** > William J. Drake > International Fellow & Lecturer > Media Change & Innovation Division, IPMZ > University of Zurich, Switzerland > Chair, Noncommercial Users Constituency, > ICANN, www.ncuc.org > william.drake at uzh.ch > (direct), wjdrake at gmail.com > (lists), > www.williamdrake.org > *********************************************** > From rafik.dammak Fri Aug 8 20:08:59 2014 From: rafik.dammak (Rafik Dammak) Date: Sat, 9 Aug 2014 02:08:59 +0900 Subject: [PC-NCSG] [NCSG-Discuss] Fairly Urgent: Possible Joint Statement on Accountability In-Reply-To: <53E4CC98.1040004@acm.org> References: <53E4CC98.1040004@acm.org> Message-ID: Hi Avri, to explain the context leading to to this statement proposal. there was mail thread between GNSO stakeholders groups/constituencies chairs after that famous "leaders" call. the discussion started by expressing concerns about the proposal presented in the call ,also highlighting about not being in alignment with it and acting quickly before being posted (hopefully to prevent the "fait accompli" typical of Fadi, but that is my personal interpretation). that is why the request was if we can get agreement on common position within few days. so the discussion is about getting GNSO groups coordinated in this issue and keeping the momentum we got in London meeting. the statement is simple since the different groups , at various levels , are working on their own responses like us (and that is why I hope the group of volunteers can do that as a first task). so those groups are discussing internally ,consulting about the proposal and the statement and we should do so too . there is no statement to be agreed by chairs only . I do think that NCSG policy committee should act on this and following the discussion we are having now in the NCSG ML , to make decision . there was also a mention that we may reach the chairs of other SO and AC, but didn't see any update about this. Best, Rafik 2014-08-08 22:11 GMT+09:00 Avri Doria : > Hi, > > I do not understand the need for it and what it achieves. > > Are we talking about the plan that have not been rolled out for review > yet? How can we be asking for more time on something they have not > asked us to review yet. > > As I understand it they gave the Leaders a peek, and some of you passed > that peek on. I am not sure what else is going on. Are they waiting > for reviews? Will they honor reviews? Or is really a done deal that > are 'agree or left behind deals'? Will we just be adding yet another > comment to be ignored - we can see the effect the previous letter had. > > I also think it is heartwarming that all you leaders have found such > kumbaya among yourselves for rapid creation of letters the rest of us > barely have time to approve. I would prefer to see a Council channel > used for these sorts of things. > > i am not in favor of the note. > > avri > > On 08-Aug-14 04:42, William Drake wrote: > > Hi > > > > Further to the discussion about staff?s proposed accountability > > mechanism, SG/constituency chairs have been discussing a possible joint > > statement. As agreeing on details regarding specific concerns might take > > some cycles and Fadi?s asked us to move quickly into alignment, Tony > > Holmes of the ISPCP has circulated this place holder for collective > > endorsement and rapid transmission. Would people be amenable to NCSG > > signing onto this for now, with more to come? Bill > > > > /During ICANN meeting 50 the entire GNSO community came together to make > > a statement calling for the Board to support community creation of an > > independent accountability mechanism. That action clearly indicates the > > importance of this issue to the community and its constituent groups. > > Since then we have closely followed this issue and are now > > considering //ICANN?s proposal for managing the accountability process. > > However at this stage it would be both prudent and timely to advise you > > that currently there is no alignment within the GNSO community on the > > proposed approach or process proposed by ICANN. Discussions are on-going > > and it is our intention to offer a more detailed statement of our > > concerns as early as possible next week./ > > / > > / > > Bill > > > > *********************************************** > > William J. Drake > > International Fellow & Lecturer > > Media Change & Innovation Division, IPMZ > > University of Zurich, Switzerland > > Chair, Noncommercial Users Constituency, > > ICANN, www.ncuc.org > > william.drake at uzh.ch > > (direct), wjdrake at gmail.com > > (lists), > > www.williamdrake.org > > *********************************************** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Fri Aug 8 22:43:43 2014 From: avri (Avri Doria) Date: Fri, 08 Aug 2014 15:43:43 -0400 Subject: [PC-NCSG] [] Fairly Urgent: Possible Joint Statement on Accountability In-Reply-To: References: <53E4CC98.1040004@acm.org> Message-ID: <53E5286F.3010603@acm.org> hi, we work on rough consensus, so if everyone else think i am wrong and want to sign up, i won't yell foul. i like the RySg letter. where can i sign on? avri From avri Mon Aug 11 15:36:43 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 08:36:43 -0400 Subject: [PC-NCSG] Fwd: draft-NCSG-Stmt-AccountabilityPlan In-Reply-To: <001a1134aeac1fa85d050059be8a@google.com> References: <001a1134aeac1fa85d050059be8a@google.com> Message-ID: <53E8B8DB.1080105@acm.org> An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: draft-NCSG-Stmt-AccountabilityPlan.pdf Type: application/pdf Size: 71203 bytes Desc: not available URL: From rafik.dammak Mon Aug 11 15:39:42 2014 From: rafik.dammak (Rafik Dammak) Date: Mon, 11 Aug 2014 21:39:42 +0900 Subject: [PC-NCSG] Fwd: draft-NCSG-Stmt-AccountabilityPlan In-Reply-To: <53E8B8DB.1080105@acm.org> References: <001a1134aeac1fa85d050059be8a@google.com> <53E8B8DB.1080105@acm.org> Message-ID: Hi Avri, thanks for reminder, we have also: - the GNSO statement to endorse - the registries statement to endorse they are not necessarily bundled. Best, Rafik 2014-08-11 21:36 GMT+09:00 Avri Doria : > (sent from wrong address) > > Do we have rough consensus on this doc. Need to decide today. > > > avri > > > -------- Original Message -------- Subject: > draft-NCSG-Stmt-AccountabilityPlan Date: Mon, 11 Aug 2014 12:32:05 +0000 From: > Avri Doria (via Google Docs) To: > doriavr at gmail.com CC: PC-NCSG at ipjustice.org > > Avri Doria has attached the following document: > [image: Document]draft-NCSG-Stmt-AccountabilityPlan > We have until Tuesday to comment > And Today, Monday, would be better. > > Do we have rough consensus on this? > > avri > > > > > > > > > > > > > > > > > > > > Google Docs: Create and edit documents online. [image: Logo for > Google Docs] > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Mon Aug 11 18:13:14 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 11:13:14 -0400 Subject: [PC-NCSG] [NCSG-Discuss] draft NCSG accountability statement In-Reply-To: <53E8D87D.9030406@gmail.com> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> Message-ID: <53E8DD8A.1080402@acm.org> Hi, I have made a few edits to the document to reflect the comments by Nicolas and Carlos. avri DRAFT Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.02 The NCSG appreciates this opportunity to provide feedback regarding the ICANN Staff?s non-stakeholder led proposal for further work on ?Enhancing Accountability? at ICANN. A number of public comments and discussions in London focused on the inherent conflict of interest behind staff developing its own accountability mechanisms, so it was surprising to see that input had not been taken into account by staff in the development of this proposal. NCSG notes its disappointment with the staff having skipped the step of providing a synthesis of the community feedback received from the ICANN public comments forum and the London accountability discussions. Staff had stated it was working on this during GNSO Council and SO/AC leadership calls since the London meeting, and that was over a month ago; normally, staff can produce a synthesis of a comment period within a week, so we are at a loss to explain this delay. NCSG reiterates its request to see the synthesis of public input upon which staff relied in the formulation of its accountability proposal. It is impossible to know where the components of staff?s proposal come from and on what basis they are called for without being privy to staff?s assessment of the public input on the subject. It is difficult to find those elements in the written comments. At a time when the world is indeed watching ICANN to discern if it can be trusted without NTIA oversight of its global governance functions, and is particularly interested in the formulation of a proposal for resolving ICANN?s accountability crisis, to skip the step of providing the rationale for staff?s proposal, including its basis in the community?s stakeholder comments, seems imprudent at best. From its inception, the community should have been engaged in the formulation of the proposal on the table, not pressured into signing-off on a staff proposal at the 11th hour. This is an example of top-down policymaking, which runs counter to ICANN?s bottom-up methodology and may inspire mistrust on the part of the stakeholders. Regarding the substance of the staff proposal, the NCSG does not support it as currently drafted. Of particular concern is the proposed Community Coordination Group, which would prioritize issues identified by the community and build solutions for those issues. As proposed by staff, this group is too heavily controlled by the ICANN board and staff and as such it replicates the problem of ICANN?s accountability structures being circular and lacking independence. Given the overwhelming number of public comments submitted supporting the need for an independent accountability mechanisms, it is unclear on what basis ICANN staff proposed a solution in which the ICANN board and staff would fill a large number of the seats on the CCG. It is also unclear on what basis staff thinks board-picked advisors should have an equal voice as representatives of community members. Outside experts are welcome and can provide valuable input, but they should be selected by and report to the community, not the board or staff for independent accountability to be achieved. And advisors? role must be clarified as an informational role, rather than a decision making role that representatives of stakeholder interests would hold in a bottom-up process. It is also necessary that the role of any ICANN board or staff on this CCG serve in a non-decision making, support or liaison function. For the CCG to have legitimacy as a participatory form of democracy, the decision-making members must consist of stakeholders, not the ICANN board and staff. The make-up, roles and responsibilities of the members of the proposed CCG must be reformulated in a more bottom-up fashion by the community for this proposal to be acceptable. From avri Mon Aug 11 19:47:43 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 12:47:43 -0400 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> Message-ID: <53E8F3AF.4010708@acm.org> ok done On 11-Aug-14 12:23, Edward Morris wrote: > Hi Avri, > > Thanks for doing this. > > Would it be possible to insert the word "transparency" in the document > somewhere? I'd suggest here: > > > inherent conflict of interest behind staff developing its own > accountability *and transparency* mechanisms, so it was surprising > to see that input had > > > > but anywhere is fine. The important thing is to keep the concept alive, > and the concept of accountability broad. > DRAFT Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 The NCSG appreciates this opportunity to provide feedback regarding the ICANN Staff?s non-stakeholder led proposal for further work on ?Enhancing Accountability? at ICANN. A number of public comments and discussions in London focused on the inherent conflict of interest behind staff developing its own accountability and transparency mechanisms, so it was surprising to see that input had not been taken into account by staff in the development of this proposal. NCSG notes its disappointment with the staff having skipped the step of providing a synthesis of the community feedback received from the ICANN public comments forum and the London accountability discussions. Staff had stated it was working on this during GNSO Council and SO/AC leadership calls since the London meeting, and that was over a month ago; normally, staff can produce a synthesis of a comment period with a week, so we are at a loss to explain this delay. NCSG reiterates its request to see the synthesis of public input upon which staff relied in the formulation of its accountability proposal. It is impossible to know where the components of staff?s proposal come from and on what basis they are called for without being privy to staff?s assessment of the public input on the subject. It is difficult to find those elements in the written comments. At a time when the world is indeed watching ICANN to discern if it can be trusted without NTIA oversight of its global governance functions, and is particularly interested in the formulation of a proposal for resolving ICANN?s accountability crisis, to skip the step of providing the rationale for staff?s proposal, including its basis in the community?s stakeholder comments, seems imprudent at best. From its inception, the community should have been engaged in the formulation of the proposal on the table, not pressured into signing-off on a staff proposal at the 11th hour. This is an example of top-down policymaking, which runs counter to ICANN?s bottom-up methodology and may inspire mistrust on the part of the stakeholders. Regarding the substance of the staff proposal, the NCSG does not support it as currently drafted. Of particular concern is the proposed Community Coordination Group, which would prioritize issues identified by the community and build solutions for those issues. As proposed by staff, this group is too heavily controlled by the ICANN board and staff and as such it replicates the problem of ICANN?s accountability structures being circular and lacking independence. Given the overwhelming number of public comments submitted supporting the need for an independent accountability mechanisms, it is unclear on what basis ICANN staff proposed a solution in which the ICANN board and staff would fill a large number of the seats on the CCG. It is also unclear on what basis staff thinks board-picked advisors should have an equal voice as representatives of community members. Outside experts are welcome and can provide valuable input, but they should be selected by and report to the community, not the board or staff for independent accountability to be achieved. And advisors? role must be clarified as an informational role, rather than a decision making role that representatives of stakeholder interests would hold in a bottom-up process. It is also necessary that the role of any ICANN board or staff on this CCG serve in a non-decision making, support or liaison function. For the CCG to have legitimacy as a participatory form of democracy, the decision-making members must consist of stakeholders, not the ICANN board and staff. The make-up, roles and responsibilities of the members of the proposed CCG must be reformulated in a more bottom-up fashion by the community for this proposal to be acceptable. From avri Mon Aug 11 19:54:07 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 12:54:07 -0400 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <53E8F3AF.4010708@acm.org> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> Message-ID: <53E8F52F.7010001@acm.org> Hi, I request that we initiate an approval process for Rafik to be able to send this in as a NCSG letter. thanks avri On 11-Aug-14 12:47, Avri Doria wrote: > DRAFT > Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 > > The NCSG appreciates this opportunity to provide feedback regarding the > ICANN Staff?s non-stakeholder led proposal for further work on > ?Enhancing Accountability? at ICANN. > > A number of public comments and discussions in London focused on the > inherent conflict of interest behind staff developing its own > accountability and transparency mechanisms, so it was surprising to see > that input had not been taken into account by staff in the development > of this proposal. NCSG notes its disappointment with the staff having > skipped the step of providing a synthesis of the community feedback > received from the ICANN public comments forum and the London > accountability discussions. Staff had stated it was working on this > during GNSO Council and SO/AC leadership calls since the London meeting, > and that was over a month ago; normally, staff can produce a synthesis > of a comment period with a week, so we are at a loss to explain this > delay. NCSG reiterates its request to see the synthesis of public input > upon which staff relied in the formulation of its accountability > proposal. It is impossible to know where the components of staff?s > proposal come from and on what basis they are called for without being > privy to staff?s assessment of the public input on the subject. It is > difficult to find those elements in the written comments. At a time > when the world is indeed watching ICANN to discern if it can be trusted > without NTIA oversight of its global governance functions, and is > particularly interested in the formulation of a proposal for resolving > ICANN?s accountability crisis, to skip the step of providing the > rationale for staff?s proposal, including its basis in the community?s > stakeholder comments, seems imprudent at best. From its inception, the > community should have been engaged in the formulation of the proposal on > the table, not pressured into signing-off on a staff proposal at the > 11th hour. This is an example of top-down policymaking, which runs > counter to ICANN?s bottom-up methodology and may inspire mistrust on the > part of the stakeholders. > > Regarding the substance of the staff proposal, the NCSG does not support > it as currently drafted. Of particular concern is the proposed > Community Coordination Group, which would prioritize issues identified > by the community and build solutions for those issues. As proposed by > staff, this group is too heavily controlled by the ICANN board and staff > and as such it replicates the problem of ICANN?s accountability > structures being circular and lacking independence. Given the > overwhelming number of public comments submitted supporting the need for > an independent accountability mechanisms, it is unclear on what basis > ICANN staff proposed a solution in which the ICANN board and staff would > fill a large number of the seats on the CCG. It is also unclear on what > basis staff thinks board-picked advisors should have an equal voice as > representatives of community members. Outside experts are welcome and > can provide valuable input, but they should be selected by and report to > the community, not the board or staff for independent accountability to > be achieved. And advisors? role must be clarified as an informational > role, rather than a decision making role that representatives of > stakeholder interests would hold in a bottom-up process. It is also > necessary that the role of any ICANN board or staff on this CCG serve in > a non-decision making, support or liaison function. For the CCG to > have legitimacy as a participatory form of democracy, the > decision-making members must consist of stakeholders, not the ICANN > board and staff. The make-up, roles and responsibilities of the members > of the proposed CCG must be reformulated in a more bottom-up fashion by > the community for this proposal to be acceptable. > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > From stephanie.perrin Mon Aug 11 20:19:24 2014 From: stephanie.perrin (Stephanie Perrin) Date: Mon, 11 Aug 2014 13:19:24 -0400 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <53E8F52F.7010001@acm.org> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> Message-ID: <53E8FB1C.1060405@mail.utoronto.ca> I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. cheers Stephanie On 2014-08-11, 12:54, Avri Doria wrote: > Hi, > > I request that we initiate an approval process for Rafik to be able to > send this in as a NCSG letter. > > thanks > > avri > > On 11-Aug-14 12:47, Avri Doria wrote: > >> DRAFT >> Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 >> >> The NCSG appreciates this opportunity to provide feedback regarding the >> ICANN Staff?s non-stakeholder led proposal for further work on >> ?Enhancing Accountability? at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising to see >> that input had not been taken into account by staff in the development >> of this proposal. NCSG notes its disappointment with the staff having >> skipped the step of providing a synthesis of the community feedback >> received from the ICANN public comments forum and the London >> accountability discussions. Staff had stated it was working on this >> during GNSO Council and SO/AC leadership calls since the London meeting, >> and that was over a month ago; normally, staff can produce a synthesis >> of a comment period with a week, so we are at a loss to explain this >> delay. NCSG reiterates its request to see the synthesis of public input >> upon which staff relied in the formulation of its accountability >> proposal. It is impossible to know where the components of staff?s >> proposal come from and on what basis they are called for without being >> privy to staff?s assessment of the public input on the subject. It is >> difficult to find those elements in the written comments. At a time >> when the world is indeed watching ICANN to discern if it can be trusted >> without NTIA oversight of its global governance functions, and is >> particularly interested in the formulation of a proposal for resolving >> ICANN?s accountability crisis, to skip the step of providing the >> rationale for staff?s proposal, including its basis in the community?s >> stakeholder comments, seems imprudent at best. From its inception, the >> community should have been engaged in the formulation of the proposal on >> the table, not pressured into signing-off on a staff proposal at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group, which would prioritize issues identified >> by the community and build solutions for those issues. As proposed by >> staff, this group is too heavily controlled by the ICANN board and staff >> and as such it replicates the problem of ICANN?s accountability >> structures being circular and lacking independence. Given the >> overwhelming number of public comments submitted supporting the need for >> an independent accountability mechanisms, it is unclear on what basis >> ICANN staff proposed a solution in which the ICANN board and staff would >> fill a large number of the seats on the CCG. It is also unclear on what >> basis staff thinks board-picked advisors should have an equal voice as >> representatives of community members. Outside experts are welcome and >> can provide valuable input, but they should be selected by and report to >> the community, not the board or staff for independent accountability to >> be achieved. And advisors? role must be clarified as an informational >> role, rather than a decision making role that representatives of >> stakeholder interests would hold in a bottom-up process. It is also >> necessary that the role of any ICANN board or staff on this CCG serve in >> a non-decision making, support or liaison function. For the CCG to >> have legitimacy as a participatory form of democracy, the >> decision-making members must consist of stakeholders, not the ICANN >> board and staff. The make-up, roles and responsibilities of the members >> of the proposed CCG must be reformulated in a more bottom-up fashion by >> the community for this proposal to be acceptable. >> >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg From dave Mon Aug 11 20:29:27 2014 From: dave (David Cake) Date: Mon, 11 Aug 2014 19:29:27 +0200 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <53E8FB1C.1060405@mail.utoronto.ca> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> Message-ID: <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> I agree. It looks good to me. Happy to endorse it. On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. cheers Stephanie On 2014-08-11, 12:54, Avri Doria wrote: Hi, I request that we initiate an approval process for Rafik to be able to send this in as a NCSG letter. thanks avri On 11-Aug-14 12:47, Avri Doria wrote: DRAFT Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 The NCSG appreciates this opportunity to provide feedback regarding the ICANN Staff?s non-stakeholder led proposal for further work on ?Enhancing Accountability? at ICANN. A number of public comments and discussions in London focused on the inherent conflict of interest behind staff developing its own accountability and transparency mechanisms, so it was surprising to see that input had not been taken into account by staff in the development of this proposal. NCSG notes its disappointment with the staff having skipped the step of providing a synthesis of the community feedback received from the ICANN public comments forum and the London accountability discussions. Staff had stated it was working on this during GNSO Council and SO/AC leadership calls since the London meeting, and that was over a month ago; normally, staff can produce a synthesis of a comment period with a week, so we are at a loss to explain this delay. NCSG reiterates its request to see the synthesis of public input upon which staff relied in the formulation of its accountability proposal. It is impossible to know where the components of staff?s proposal come from and on what basis they are called for without being privy to staff?s assessment of the public input on the subject. It is difficult to find those elements in the written comments. At a time when the world is indeed watching ICANN to discern if it can be trusted without NTIA oversight of its global governance functions, and is particularly interested in the formulation of a proposal for resolving ICANN?s accountability crisis, to skip the step of providing the rationale for staff?s proposal, including its basis in the community?s stakeholder comments, seems imprudent at best. From its inception, the community should have been engaged in the formulation of the proposal on the table, not pressured into signing-off on a staff proposal at the 11th hour. This is an example of top-down policymaking, which runs counter to ICANN?s bottom-up methodology and may inspire mistrust on the part of the stakeholders. Regarding the substance of the staff proposal, the NCSG does not support it as currently drafted. Of particular concern is the proposed Community Coordination Group, which would prioritize issues identified by the community and build solutions for those issues. As proposed by staff, this group is too heavily controlled by the ICANN board and staff and as such it replicates the problem of ICANN?s accountability structures being circular and lacking independence. Given the overwhelming number of public comments submitted supporting the need for an independent accountability mechanisms, it is unclear on what basis ICANN staff proposed a solution in which the ICANN board and staff would fill a large number of the seats on the CCG. It is also unclear on what basis staff thinks board-picked advisors should have an equal voice as representatives of community members. Outside experts are welcome and can provide valuable input, but they should be selected by and report to the community, not the board or staff for independent accountability to be achieved. And advisors? role must be clarified as an informational role, rather than a decision making role that representatives of stakeholder interests would hold in a bottom-up process. It is also necessary that the role of any ICANN board or staff on this CCG serve in a non-decision making, support or liaison function. For the CCG to have legitimacy as a participatory form of democracy, the decision-making members must consist of stakeholders, not the ICANN board and staff. The make-up, roles and responsibilities of the members of the proposed CCG must be reformulated in a more bottom-up fashion by the community for this proposal to be acceptable. _______________________________________________ PC-NCSG mailing list PC-NCSG at ipjustice.org http://mailman.ipjustice.org/listinfo/pc-ncsg _______________________________________________ PC-NCSG mailing list PC-NCSG at ipjustice.org http://mailman.ipjustice.org/listinfo/pc-ncsg _______________________________________________ PC-NCSG mailing list PC-NCSG at ipjustice.org http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robin Mon Aug 11 23:01:24 2014 From: robin (Robin Gross) Date: Mon, 11 Aug 2014 13:01:24 -0700 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> Message-ID: Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. Thanks, Robin On Aug 11, 2014, at 10:29 AM, David Cake wrote: > I agree. It looks good to me. Happy to endorse it. > > On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: > > I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. > cheers Stephanie > On 2014-08-11, 12:54, Avri Doria wrote: > Hi, > > I request that we initiate an approval process for Rafik to be able to > send this in as a NCSG letter. > > thanks > > avri > > On 11-Aug-14 12:47, Avri Doria wrote: > > DRAFT > Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 > > The NCSG appreciates this opportunity to provide feedback regarding the > ICANN Staff?s non-stakeholder led proposal for further work on > ?Enhancing Accountability? at ICANN. > > A number of public comments and discussions in London focused on the > inherent conflict of interest behind staff developing its own > accountability and transparency mechanisms, so it was surprising to see > that input had not been taken into account by staff in the development > of this proposal. NCSG notes its disappointment with the staff having > skipped the step of providing a synthesis of the community feedback > received from the ICANN public comments forum and the London > accountability discussions. Staff had stated it was working on this > during GNSO Council and SO/AC leadership calls since the London meeting, > and that was over a month ago; normally, staff can produce a synthesis > of a comment period with a week, so we are at a loss to explain this > delay. NCSG reiterates its request to see the synthesis of public input > upon which staff relied in the formulation of its accountability > proposal. It is impossible to know where the components of staff?s > proposal come from and on what basis they are called for without being > privy to staff?s assessment of the public input on the subject. It is > difficult to find those elements in the written comments. At a time > when the world is indeed watching ICANN to discern if it can be trusted > without NTIA oversight of its global governance functions, and is > particularly interested in the formulation of a proposal for resolving > ICANN?s accountability crisis, to skip the step of providing the > rationale for staff?s proposal, including its basis in the community?s > stakeholder comments, seems imprudent at best. From its inception, the > community should have been engaged in the formulation of the proposal on > the table, not pressured into signing-off on a staff proposal at the > 11th hour. This is an example of top-down policymaking, which runs > counter to ICANN?s bottom-up methodology and may inspire mistrust on the > part of the stakeholders. > > Regarding the substance of the staff proposal, the NCSG does not support > it as currently drafted. Of particular concern is the proposed > Community Coordination Group, which would prioritize issues identified > by the community and build solutions for those issues. As proposed by > staff, this group is too heavily controlled by the ICANN board and staff > and as such it replicates the problem of ICANN?s accountability > structures being circular and lacking independence. Given the > overwhelming number of public comments submitted supporting the need for > an independent accountability mechanisms, it is unclear on what basis > ICANN staff proposed a solution in which the ICANN board and staff would > fill a large number of the seats on the CCG. It is also unclear on what > basis staff thinks board-picked advisors should have an equal voice as > representatives of community members. Outside experts are welcome and > can provide valuable input, but they should be selected by and report to > the community, not the board or staff for independent accountability to > be achieved. And advisors? role must be clarified as an informational > role, rather than a decision making role that representatives of > stakeholder interests would hold in a bottom-up process. It is also > necessary that the role of any ICANN board or staff on this CCG serve in > a non-decision making, support or liaison function. For the CCG to > have legitimacy as a participatory form of democracy, the > decision-making members must consist of stakeholders, not the ICANN > board and staff. The make-up, roles and responsibilities of the members > of the proposed CCG must be reformulated in a more bottom-up fashion by > the community for this proposal to be acceptable. > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stephanie.perrin Tue Aug 12 00:26:53 2014 From: stephanie.perrin (Stephanie Perrin) Date: Mon, 11 Aug 2014 17:26:53 -0400 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> Message-ID: <53E9351D.6040005@mail.utoronto.ca> Yes, go go go On 2014-08-11, 16:01, Robin Gross wrote: > Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. > > Thanks, > Robin > > On Aug 11, 2014, at 10:29 AM, David Cake wrote: > >> I agree. It looks good to me. Happy to endorse it. >> >> On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: >> >> I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. >> cheers Stephanie >> On 2014-08-11, 12:54, Avri Doria wrote: >> Hi, >> >> I request that we initiate an approval process for Rafik to be able to >> send this in as a NCSG letter. >> >> thanks >> >> avri >> >> On 11-Aug-14 12:47, Avri Doria wrote: >> >> DRAFT >> Proposed NCSG Statement on ICANN Staff's Accountability Plan v.03 >> >> The NCSG appreciates this opportunity to provide feedback regarding the >> ICANN Staff's non-stakeholder led proposal for further work on >> "Enhancing Accountability" at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising to see >> that input had not been taken into account by staff in the development >> of this proposal. NCSG notes its disappointment with the staff having >> skipped the step of providing a synthesis of the community feedback >> received from the ICANN public comments forum and the London >> accountability discussions. Staff had stated it was working on this >> during GNSO Council and SO/AC leadership calls since the London meeting, >> and that was over a month ago; normally, staff can produce a synthesis >> of a comment period with a week, so we are at a loss to explain this >> delay. NCSG reiterates its request to see the synthesis of public input >> upon which staff relied in the formulation of its accountability >> proposal. It is impossible to know where the components of staff's >> proposal come from and on what basis they are called for without being >> privy to staff's assessment of the public input on the subject. It is >> difficult to find those elements in the written comments. At a time >> when the world is indeed watching ICANN to discern if it can be trusted >> without NTIA oversight of its global governance functions, and is >> particularly interested in the formulation of a proposal for resolving >> ICANN's accountability crisis, to skip the step of providing the >> rationale for staff's proposal, including its basis in the community's >> stakeholder comments, seems imprudent at best. From its inception, the >> community should have been engaged in the formulation of the proposal on >> the table, not pressured into signing-off on a staff proposal at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN's bottom-up methodology and may inspire mistrust on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group, which would prioritize issues identified >> by the community and build solutions for those issues. As proposed by >> staff, this group is too heavily controlled by the ICANN board and staff >> and as such it replicates the problem of ICANN's accountability >> structures being circular and lacking independence. Given the >> overwhelming number of public comments submitted supporting the need for >> an independent accountability mechanisms, it is unclear on what basis >> ICANN staff proposed a solution in which the ICANN board and staff would >> fill a large number of the seats on the CCG. It is also unclear on what >> basis staff thinks board-picked advisors should have an equal voice as >> representatives of community members. Outside experts are welcome and >> can provide valuable input, but they should be selected by and report to >> the community, not the board or staff for independent accountability to >> be achieved. And advisors' role must be clarified as an informational >> role, rather than a decision making role that representatives of >> stakeholder interests would hold in a bottom-up process. It is also >> necessary that the role of any ICANN board or staff on this CCG serve in >> a non-decision making, support or liaison function. For the CCG to >> have legitimacy as a participatory form of democracy, the >> decision-making members must consist of stakeholders, not the ICANN >> board and staff. The make-up, roles and responsibilities of the members >> of the proposed CCG must be reformulated in a more bottom-up fashion by >> the community for this proposal to be acceptable. >> >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin Tue Aug 12 03:59:19 2014 From: robin (Robin Gross) Date: Mon, 11 Aug 2014 17:59:19 -0700 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <53E9351D.6040005@mail.utoronto.ca> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> <53E9351D.6040005@mail.utoronto.ca> Message-ID: Hi Maria & Rudi, Can we submit the NCSG stmt now? Thanks, Robin On Aug 11, 2014, at 2:26 PM, Stephanie Perrin wrote: > Yes, go go go > On 2014-08-11, 16:01, Robin Gross wrote: >> Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. >> >> Thanks, >> Robin >> >> On Aug 11, 2014, at 10:29 AM, David Cake wrote: >> >>> I agree. It looks good to me. Happy to endorse it. >>> >>> On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: >>> >>> I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. >>> cheers Stephanie >>> On 2014-08-11, 12:54, Avri Doria wrote: >>> Hi, >>> >>> I request that we initiate an approval process for Rafik to be able to >>> send this in as a NCSG letter. >>> >>> thanks >>> >>> avri >>> >>> On 11-Aug-14 12:47, Avri Doria wrote: >>> >>> DRAFT >>> Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 >>> >>> The NCSG appreciates this opportunity to provide feedback regarding the >>> ICANN Staff?s non-stakeholder led proposal for further work on >>> ?Enhancing Accountability? at ICANN. >>> >>> A number of public comments and discussions in London focused on the >>> inherent conflict of interest behind staff developing its own >>> accountability and transparency mechanisms, so it was surprising to see >>> that input had not been taken into account by staff in the development >>> of this proposal. NCSG notes its disappointment with the staff having >>> skipped the step of providing a synthesis of the community feedback >>> received from the ICANN public comments forum and the London >>> accountability discussions. Staff had stated it was working on this >>> during GNSO Council and SO/AC leadership calls since the London meeting, >>> and that was over a month ago; normally, staff can produce a synthesis >>> of a comment period with a week, so we are at a loss to explain this >>> delay. NCSG reiterates its request to see the synthesis of public input >>> upon which staff relied in the formulation of its accountability >>> proposal. It is impossible to know where the components of staff?s >>> proposal come from and on what basis they are called for without being >>> privy to staff?s assessment of the public input on the subject. It is >>> difficult to find those elements in the written comments. At a time >>> when the world is indeed watching ICANN to discern if it can be trusted >>> without NTIA oversight of its global governance functions, and is >>> particularly interested in the formulation of a proposal for resolving >>> ICANN?s accountability crisis, to skip the step of providing the >>> rationale for staff?s proposal, including its basis in the community?s >>> stakeholder comments, seems imprudent at best. From its inception, the >>> community should have been engaged in the formulation of the proposal on >>> the table, not pressured into signing-off on a staff proposal at the >>> 11th hour. This is an example of top-down policymaking, which runs >>> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >>> part of the stakeholders. >>> >>> Regarding the substance of the staff proposal, the NCSG does not support >>> it as currently drafted. Of particular concern is the proposed >>> Community Coordination Group, which would prioritize issues identified >>> by the community and build solutions for those issues. As proposed by >>> staff, this group is too heavily controlled by the ICANN board and staff >>> and as such it replicates the problem of ICANN?s accountability >>> structures being circular and lacking independence. Given the >>> overwhelming number of public comments submitted supporting the need for >>> an independent accountability mechanisms, it is unclear on what basis >>> ICANN staff proposed a solution in which the ICANN board and staff would >>> fill a large number of the seats on the CCG. It is also unclear on what >>> basis staff thinks board-picked advisors should have an equal voice as >>> representatives of community members. Outside experts are welcome and >>> can provide valuable input, but they should be selected by and report to >>> the community, not the board or staff for independent accountability to >>> be achieved. And advisors? role must be clarified as an informational >>> role, rather than a decision making role that representatives of >>> stakeholder interests would hold in a bottom-up process. It is also >>> necessary that the role of any ICANN board or staff on this CCG serve in >>> a non-decision making, support or liaison function. For the CCG to >>> have legitimacy as a participatory form of democracy, the >>> decision-making members must consist of stakeholders, not the ICANN >>> board and staff. The make-up, roles and responsibilities of the members >>> of the proposed CCG must be reformulated in a more bottom-up fashion by >>> the community for this proposal to be acceptable. >>> >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rafik.dammak Tue Aug 12 04:28:37 2014 From: rafik.dammak (Rafik Dammak) Date: Tue, 12 Aug 2014 10:28:37 +0900 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> <53E9351D.6040005@mail.utoronto.ca> Message-ID: Hi , @Robin can you please share the latest version for reference. I want to request that we also : - endorse Registries statement (latest version co-signed with BC) which was supported in NCSG mailing list - endorse the short GNSO common statement, I think Avri expressed objection but I don't know if she agrees with it now. we should respond today to be in time and be effective. Best, Rafik 2014-08-12 9:59 GMT+09:00 Robin Gross : > Hi Maria & Rudi, > > Can we submit the NCSG stmt now? > > Thanks, > Robin > > On Aug 11, 2014, at 2:26 PM, Stephanie Perrin wrote: > > Yes, go go go > On 2014-08-11, 16:01, Robin Gross wrote: > > Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. > > Thanks, > Robin > > On Aug 11, 2014, at 10:29 AM, David Cake wrote: > > > I agree. It looks good to me. Happy to endorse it. > > On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: > > I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. > cheers Stephanie > On 2014-08-11, 12:54, Avri Doria wrote: > Hi, > > I request that we initiate an approval process for Rafik to be able to > send this in as a NCSG letter. > > thanks > > avri > > On 11-Aug-14 12:47, Avri Doria wrote: > > DRAFT > Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 > > The NCSG appreciates this opportunity to provide feedback regarding the > ICANN Staff?s non-stakeholder led proposal for further work on > ?Enhancing Accountability? at ICANN. > > A number of public comments and discussions in London focused on the > inherent conflict of interest behind staff developing its own > accountability and transparency mechanisms, so it was surprising to see > that input had not been taken into account by staff in the development > of this proposal. NCSG notes its disappointment with the staff having > skipped the step of providing a synthesis of the community feedback > received from the ICANN public comments forum and the London > accountability discussions. Staff had stated it was working on this > during GNSO Council and SO/AC leadership calls since the London meeting, > and that was over a month ago; normally, staff can produce a synthesis > of a comment period with a week, so we are at a loss to explain this > delay. NCSG reiterates its request to see the synthesis of public input > upon which staff relied in the formulation of its accountability > proposal. It is impossible to know where the components of staff?s > proposal come from and on what basis they are called for without being > privy to staff?s assessment of the public input on the subject. It is > difficult to find those elements in the written comments. At a time > when the world is indeed watching ICANN to discern if it can be trusted > without NTIA oversight of its global governance functions, and is > particularly interested in the formulation of a proposal for resolving > ICANN?s accountability crisis, to skip the step of providing the > rationale for staff?s proposal, including its basis in the community?s > stakeholder comments, seems imprudent at best. From its inception, the > community should have been engaged in the formulation of the proposal on > the table, not pressured into signing-off on a staff proposal at the > 11th hour. This is an example of top-down policymaking, which runs > counter to ICANN?s bottom-up methodology and may inspire mistrust on the > part of the stakeholders. > > Regarding the substance of the staff proposal, the NCSG does not support > it as currently drafted. Of particular concern is the proposed > Community Coordination Group, which would prioritize issues identified > by the community and build solutions for those issues. As proposed by > staff, this group is too heavily controlled by the ICANN board and staff > and as such it replicates the problem of ICANN?s accountability > structures being circular and lacking independence. Given the > overwhelming number of public comments submitted supporting the need for > an independent accountability mechanisms, it is unclear on what basis > ICANN staff proposed a solution in which the ICANN board and staff would > fill a large number of the seats on the CCG. It is also unclear on what > basis staff thinks board-picked advisors should have an equal voice as > representatives of community members. Outside experts are welcome and > can provide valuable input, but they should be selected by and report to > the community, not the board or staff for independent accountability to > be achieved. And advisors? role must be clarified as an informational > role, rather than a decision making role that representatives of > stakeholder interests would hold in a bottom-up process. It is also > necessary that the role of any ICANN board or staff on this CCG serve in > a non-decision making, support or liaison function. For the CCG to > have legitimacy as a participatory form of democracy, the > decision-making members must consist of stakeholders, not the ICANN > board and staff. The make-up, roles and responsibilities of the members > of the proposed CCG must be reformulated in a more bottom-up fashion by > the community for this proposal to be acceptable. > > > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft Public Comment on ICANN Proposal - [BC edits].docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 26236 bytes Desc: not available URL: From rafik.dammak Tue Aug 12 04:31:43 2014 From: rafik.dammak (Rafik Dammak) Date: Tue, 12 Aug 2014 10:31:43 +0900 Subject: [PC-NCSG] Joint RySG and BC Position Statement on ICANN Staff's Proposed Accountability Process Message-ID: here the final version of registries statement, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Joint Statement on ICANN Staff Proposal -- ICANN Accountability Process FINAL.pdf Type: application/pdf Size: 51151 bytes Desc: not available URL: From avri Tue Aug 12 06:17:51 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 23:17:51 -0400 Subject: [PC-NCSG] Letter to send Message-ID: <53E9875F.7060201@acm.org> I suggest that Rafik send this version. I added Ron's edit, sort of, to Cintra's version.at this point i think that a note saying we need more time to comment seems to have been overcome by events. but i don't really care, if singing it makes us seem more together with the other SGs, so be it. And sure I support endorsing the RySG stmt. But why since we have our own. avri ----- NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 The NCSG appreciates this opportunity to provide feedback regarding the ICANN Staff?s non-stakeholder led proposal for further work on ?Enhancing Accountability? at ICANN. A number of public comments and discussions in London focused on the inherent conflict of interest behind staff developing its own accountability and transparency mechanisms, so it was surprising to see that input had not been taken into account in the development of this proposal. NCSG notes its disappointment with the staff having skipped the step of providing a synthesis of the community feedback received from the ICANN public comments forum and the London accountability discussions. Over a month ago, staff assured it was working on this during GNSO Council and SO/AC leadership calls since the London meeting; normally, staff can produce a synthesis of a comment period within a week, so we are at a loss to explain this delay. NCSG reiterates its request to see the synthesis of public input upon which staff relied in the formulation of its accountability proposal. It is impossible to know where the components of staff?s proposal come from and on what basis they are called for, without being privy to staff?s assessment of the public input on the subject. It is difficult to find those elements in the written comments to effectively evaluate the proposal. At a time when the world is indeed watching ICANN to discern if it can be trusted without NTIA oversight of its global governance functions, and is particularly interested in the formulation of a proposal for resolving ICANN?s accountability crisis; to skip the step of providing the rationale for staff?s proposal, including its basis in the community?s stakeholder comments, seems imprudent at best. From its inception, the community should have been engaged in the formulation of the proposal, not pressured into signing-off on a staff proposal at the 11th hour. This is an example of top-down policymaking, which runs counter to ICANN?s bottom-up methodology and may inspire mistrust on the part of the stakeholders. Regarding the substance of the staff proposal, the NCSG does not support it as currently drafted. Of particular concern is the proposed Community Coordination Group (CCG), which would prioritize issues identified by the community and build solutions for those issues. As proposed by staff, this group is too heavily controlled by the ICANN board and staff and as such it replicates the problem of ICANN?s accountability structures being circular and lacking independence. We reiterate that given the overwhelming number of public comments submitted supporting the need for an independent accountability mechanisms, it is unclear on what basis ICANN staff proposed a solution in which the ICANN board and staff would fill a large number of the seats on the CCG. It is also unclear on what basis staff thinks board-picked advisors should have an equal voice as representatives of community members. Outside experts are welcome and can provide valuable input, but they should be selected by and report to the community not the board or staff, for independent accountability to be achieved. An advisor's role must be clarified as an informational role, as only representatives of stakeholder interests in a bottom-up process hold decision making roles. It is also necessary that the role of any ICANN board or staff on this CCG serve in a non-decision making, support or liaison function. For the CCG to have legitimacy as a participatory form of democracy, the decision-making members must consist of stakeholders, not the ICANN board and staff. The make-up, roles and responsibilities of the members of the proposed CCG must be reformulated in a more bottom-up fashion by the community for this proposal to be acceptable. -------------- next part -------------- A non-text attachment was scrubbed... Name: NCSG-Stmt-AccountabilityPlan.pdf Type: application/pdf Size: 72230 bytes Desc: not available URL: From avri Tue Aug 12 06:28:44 2014 From: avri (Avri Doria) Date: Mon, 11 Aug 2014 23:28:44 -0400 Subject: [PC-NCSG] Fwd: [CWG-DT-Stewardship] Latest Draft Charter -- Final Edits due at 23:59 UTC on 12 August (in 22 hours!) In-Reply-To: References: Message-ID: <53E989EC.7010702@acm.org> Hi, The charter for the IANA Stewardship Transition (IST) Cross-community Working Group (CWG) is attached. This version is on our last call for sending to the chartering groups (ALAC, ccNSO, gNSO, SSAC). We need to finish it by Tuesday UTC midnight in order for the ccNSO to be able to present it at their next meeting. avri -------- Original Message -------- Subject: [CWG-DT-Stewardship] Latest Draft Charter -- Final Edits due at 23:59 UTC on 12 August (in 22 hours!) Date: Tue, 12 Aug 2014 01:59:39 +0000 From: Grace Abuhamad To: CWG-DT-Stewardship at icann.org Hi all, Attached are two versions of the updated draft charter (redline and clean). I used Stephanie's "minor edits" document as the base for the rest of the proposed changes. I've outlined the changes I made for your reference: * Section II: Included Julie's text (first sentence of "Goals & Objectives" section) * Section III: Deleted everything except for the first sentence in point 2 of the work plan, upon Chuck's suggestion. * Section IV: o Included Stephanie's text. o Completed text relating to staff assignment in "Staffing & Resources" (Grace/Staff). o Included Allan's text on resourcing (/can the DT confirm the placement of the text in the charter?/). Note: I am missing text from Byron, but I left the text discussed on the call as a placeholder. /*Final edits are due at 23:59 UTC on 12 August (in 22 hours!).*/ Please let me know if you would like to schedule a final call. - Grace -------------- next part -------------- A non-text attachment was scrubbed... Name: DT Charter Template - clean - 12 August 2014.doc Type: application/msword Size: 138752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DT Charter Template - redline - 12 August 2014.doc Type: application/msword Size: 141824 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ CWG-DT-Stewardship mailing list CWG-DT-Stewardship at icann.org https://mm.icann.org/mailman/listinfo/cwg-dt-stewardship From rafik.dammak Tue Aug 12 10:08:45 2014 From: rafik.dammak (Rafik Dammak) Date: Tue, 12 Aug 2014 16:08:45 +0900 Subject: [PC-NCSG] Letter to send In-Reply-To: <53E9875F.7060201@acm.org> References: <53E9875F.7060201@acm.org> Message-ID: Hi Avri, if we don't hear in the next 5 hours any objections (And we didn't see any before), we can assume the statement reached consensus and can be sent. I will wait and proceed after that deadline. thanks for sharing the final and clean version. Best, Rafik 2014-08-12 12:17 GMT+09:00 Avri Doria : > I suggest that Rafik send this version. I added Ron's edit, sort of, to > Cintra's version.at this point i think that a note saying we need more > time to comment seems to have been overcome by events. but i don't > really care, if singing it makes us seem more together with the other > SGs, so be it. > > And sure I support endorsing the RySG stmt. > But why since we have our own. > > > > > avri > > ----- > > > NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 > > The NCSG appreciates this opportunity to provide feedback regarding the > ICANN Staff?s non-stakeholder led proposal for further work on > ?Enhancing Accountability? at ICANN. > > A number of public comments and discussions in London focused on the > inherent conflict of interest behind staff developing its own > accountability and transparency mechanisms, so it was surprising to see > that input had not been taken into account in the development of this > proposal. NCSG notes its disappointment with the staff having skipped > the step of providing a synthesis of the community feedback received > from the ICANN public comments forum and the London accountability > discussions. Over a month ago, staff assured it was working on this > during GNSO Council and SO/AC leadership calls since the London meeting; > normally, staff can produce a synthesis of a comment period within a > week, so we are at a loss to explain this delay. > > NCSG reiterates its request to see the synthesis of public input upon > which staff relied in the formulation of its accountability proposal. > It is impossible to know where the components of staff?s proposal come > from and on what basis they are called for, without being privy to > staff?s assessment of the public input on the subject. It is difficult > to find those elements in the written comments to effectively evaluate > the proposal. > > At a time when the world is indeed watching ICANN to discern if it can > be trusted without NTIA oversight of its global governance functions, > and is particularly interested in the formulation of a proposal for > resolving ICANN?s accountability crisis; to skip the step of providing > the rationale for staff?s proposal, including its basis in the > community?s stakeholder comments, seems imprudent at best. From its > inception, the community should have been engaged in the formulation of > the proposal, not pressured into signing-off on a staff proposal at the > 11th hour. This is an example of top-down policymaking, which runs > counter to ICANN?s bottom-up methodology and may inspire mistrust on the > part of the stakeholders. > > Regarding the substance of the staff proposal, the NCSG does not support > it as currently drafted. Of particular concern is the proposed > Community Coordination Group (CCG), which would prioritize issues > identified by the community and build solutions for those issues. As > proposed by staff, this group is too heavily controlled by the ICANN > board and staff and as such it replicates the problem of ICANN?s > accountability structures being circular and lacking independence. > > We reiterate that given the overwhelming number of public comments > submitted supporting the need for an independent accountability > mechanisms, it is unclear on what basis ICANN staff proposed a solution > in which the ICANN board and staff would fill a large number of the > seats on the CCG. It is also unclear on what basis staff thinks > board-picked advisors should have an equal voice as representatives of > community members. Outside experts are welcome and can provide valuable > input, but they should be selected by and report to the community not > the board or staff, for independent accountability to be achieved. > > An advisor's role must be clarified as an informational role, as only > representatives of stakeholder interests in a bottom-up process hold > decision making roles. It is also necessary that the role of any ICANN > board or staff on this CCG serve in a non-decision making, support or > liaison function. For the CCG to have legitimacy as a participatory > form of democracy, the decision-making members must consist of > stakeholders, not the ICANN board and staff. The make-up, roles and > responsibilities of the members of the proposed CCG must be reformulated > in a more bottom-up fashion by the community for this proposal to be > acceptable. > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin Tue Aug 12 18:25:16 2014 From: robin (Robin Gross) Date: Tue, 12 Aug 2014 08:25:16 -0700 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> <53E9351D.6040005@mail.utoronto.ca> Message-ID: <9F679F2F-8322-49E0-B93C-F1CF6F927492@ipjustice.org> May we please submit this NCSG stmt now? If we lose another day, it will be too late for any of it to matter. Sigh, Robin On Aug 11, 2014, at 5:59 PM, Robin Gross wrote: > Hi Maria & Rudi, > > Can we submit the NCSG stmt now? > > Thanks, > Robin > > On Aug 11, 2014, at 2:26 PM, Stephanie Perrin wrote: > >> Yes, go go go >> On 2014-08-11, 16:01, Robin Gross wrote: >>> Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. >>> >>> Thanks, >>> Robin >>> >>> On Aug 11, 2014, at 10:29 AM, David Cake wrote: >>> >>>> I agree. It looks good to me. Happy to endorse it. >>>> >>>> On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: >>>> >>>> I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. >>>> cheers Stephanie >>>> On 2014-08-11, 12:54, Avri Doria wrote: >>>> Hi, >>>> >>>> I request that we initiate an approval process for Rafik to be able to >>>> send this in as a NCSG letter. >>>> >>>> thanks >>>> >>>> avri >>>> >>>> On 11-Aug-14 12:47, Avri Doria wrote: >>>> >>>> DRAFT >>>> Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 >>>> >>>> The NCSG appreciates this opportunity to provide feedback regarding the >>>> ICANN Staff?s non-stakeholder led proposal for further work on >>>> ?Enhancing Accountability? at ICANN. >>>> >>>> A number of public comments and discussions in London focused on the >>>> inherent conflict of interest behind staff developing its own >>>> accountability and transparency mechanisms, so it was surprising to see >>>> that input had not been taken into account by staff in the development >>>> of this proposal. NCSG notes its disappointment with the staff having >>>> skipped the step of providing a synthesis of the community feedback >>>> received from the ICANN public comments forum and the London >>>> accountability discussions. Staff had stated it was working on this >>>> during GNSO Council and SO/AC leadership calls since the London meeting, >>>> and that was over a month ago; normally, staff can produce a synthesis >>>> of a comment period with a week, so we are at a loss to explain this >>>> delay. NCSG reiterates its request to see the synthesis of public input >>>> upon which staff relied in the formulation of its accountability >>>> proposal. It is impossible to know where the components of staff?s >>>> proposal come from and on what basis they are called for without being >>>> privy to staff?s assessment of the public input on the subject. It is >>>> difficult to find those elements in the written comments. At a time >>>> when the world is indeed watching ICANN to discern if it can be trusted >>>> without NTIA oversight of its global governance functions, and is >>>> particularly interested in the formulation of a proposal for resolving >>>> ICANN?s accountability crisis, to skip the step of providing the >>>> rationale for staff?s proposal, including its basis in the community?s >>>> stakeholder comments, seems imprudent at best. From its inception, the >>>> community should have been engaged in the formulation of the proposal on >>>> the table, not pressured into signing-off on a staff proposal at the >>>> 11th hour. This is an example of top-down policymaking, which runs >>>> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >>>> part of the stakeholders. >>>> >>>> Regarding the substance of the staff proposal, the NCSG does not support >>>> it as currently drafted. Of particular concern is the proposed >>>> Community Coordination Group, which would prioritize issues identified >>>> by the community and build solutions for those issues. As proposed by >>>> staff, this group is too heavily controlled by the ICANN board and staff >>>> and as such it replicates the problem of ICANN?s accountability >>>> structures being circular and lacking independence. Given the >>>> overwhelming number of public comments submitted supporting the need for >>>> an independent accountability mechanisms, it is unclear on what basis >>>> ICANN staff proposed a solution in which the ICANN board and staff would >>>> fill a large number of the seats on the CCG. It is also unclear on what >>>> basis staff thinks board-picked advisors should have an equal voice as >>>> representatives of community members. Outside experts are welcome and >>>> can provide valuable input, but they should be selected by and report to >>>> the community, not the board or staff for independent accountability to >>>> be achieved. And advisors? role must be clarified as an informational >>>> role, rather than a decision making role that representatives of >>>> stakeholder interests would hold in a bottom-up process. It is also >>>> necessary that the role of any ICANN board or staff on this CCG serve in >>>> a non-decision making, support or liaison function. For the CCG to >>>> have legitimacy as a participatory form of democracy, the >>>> decision-making members must consist of stakeholders, not the ICANN >>>> board and staff. The make-up, roles and responsibilities of the members >>>> of the proposed CCG must be reformulated in a more bottom-up fashion by >>>> the community for this proposal to be acceptable. >>>> >>>> >>>> >>>> _______________________________________________ >>>> PC-NCSG mailing list >>>> PC-NCSG at ipjustice.org >>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>> >>>> >>>> _______________________________________________ >>>> PC-NCSG mailing list >>>> PC-NCSG at ipjustice.org >>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>> >>>> >>>> _______________________________________________ >>>> PC-NCSG mailing list >>>> PC-NCSG at ipjustice.org >>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>> >>>> _______________________________________________ >>>> PC-NCSG mailing list >>>> PC-NCSG at ipjustice.org >>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From avri Tue Aug 12 19:11:26 2014 From: avri (Avri Doria) Date: Tue, 12 Aug 2014 12:11:26 -0400 Subject: [PC-NCSG] draft NCSG accountability statement In-Reply-To: <9F679F2F-8322-49E0-B93C-F1CF6F927492@ipjustice.org> References: <82FB208C-BBEF-4C50-A719-BE07583FB976@ipjustice.org> <53E8D87D.9030406@gmail.com> <53E8DD8A.1080402@acm.org> <53E8F3AF.4010708@acm.org> <53E8F52F.7010001@acm.org> <53E8FB1C.1060405@mail.utoronto.ca> <1E38E4B7-C41B-48A1-82E4-322F72DCC466@difference.com.au> <53E9351D.6040005@mail.utoronto.ca> <9F679F2F-8322-49E0-B93C-F1CF6F927492@ipjustice.org> Message-ID: <53EA3CAE.4010503@acm.org> Hi, you mean it did not get sent already by Rafik? Last I saw, he was going to submit. avri On 12-Aug-14 11:25, Robin Gross wrote: > May we please submit this NCSG stmt now? If we lose another day, it > will be too late for any of it to matter. > > Sigh, > Robin > > On Aug 11, 2014, at 5:59 PM, Robin Gross wrote: > >> Hi Maria & Rudi, >> >> Can we submit the NCSG stmt now? >> >> Thanks, >> Robin >> >> On Aug 11, 2014, at 2:26 PM, Stephanie Perrin wrote: >> >>> Yes, go go go >>> On 2014-08-11, 16:01, Robin Gross wrote: >>>> Thanks, all! Can we get this out today? It would be great if we could have some influence on the next draft staff publishes. >>>> >>>> Thanks, >>>> Robin >>>> >>>> On Aug 11, 2014, at 10:29 AM, David Cake wrote: >>>> >>>>> I agree. It looks good to me. Happy to endorse it. >>>>> >>>>> On 11 Aug 2014, at 7:19 pm, Stephanie Perrin wrote: >>>>> >>>>> I think the statement looks great, nice addition of the transparency item, and as a PC member I support it. >>>>> cheers Stephanie >>>>> On 2014-08-11, 12:54, Avri Doria wrote: >>>>> Hi, >>>>> >>>>> I request that we initiate an approval process for Rafik to be able to >>>>> send this in as a NCSG letter. >>>>> >>>>> thanks >>>>> >>>>> avri >>>>> >>>>> On 11-Aug-14 12:47, Avri Doria wrote: >>>>> >>>>> DRAFT >>>>> Proposed NCSG Statement on ICANN Staff?s Accountability Plan v.03 >>>>> >>>>> The NCSG appreciates this opportunity to provide feedback regarding the >>>>> ICANN Staff?s non-stakeholder led proposal for further work on >>>>> ?Enhancing Accountability? at ICANN. >>>>> >>>>> A number of public comments and discussions in London focused on the >>>>> inherent conflict of interest behind staff developing its own >>>>> accountability and transparency mechanisms, so it was surprising to see >>>>> that input had not been taken into account by staff in the development >>>>> of this proposal. NCSG notes its disappointment with the staff having >>>>> skipped the step of providing a synthesis of the community feedback >>>>> received from the ICANN public comments forum and the London >>>>> accountability discussions. Staff had stated it was working on this >>>>> during GNSO Council and SO/AC leadership calls since the London meeting, >>>>> and that was over a month ago; normally, staff can produce a synthesis >>>>> of a comment period with a week, so we are at a loss to explain this >>>>> delay. NCSG reiterates its request to see the synthesis of public input >>>>> upon which staff relied in the formulation of its accountability >>>>> proposal. It is impossible to know where the components of staff?s >>>>> proposal come from and on what basis they are called for without being >>>>> privy to staff?s assessment of the public input on the subject. It is >>>>> difficult to find those elements in the written comments. At a time >>>>> when the world is indeed watching ICANN to discern if it can be trusted >>>>> without NTIA oversight of its global governance functions, and is >>>>> particularly interested in the formulation of a proposal for resolving >>>>> ICANN?s accountability crisis, to skip the step of providing the >>>>> rationale for staff?s proposal, including its basis in the community?s >>>>> stakeholder comments, seems imprudent at best. From its inception, the >>>>> community should have been engaged in the formulation of the proposal on >>>>> the table, not pressured into signing-off on a staff proposal at the >>>>> 11th hour. This is an example of top-down policymaking, which runs >>>>> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >>>>> part of the stakeholders. >>>>> >>>>> Regarding the substance of the staff proposal, the NCSG does not support >>>>> it as currently drafted. Of particular concern is the proposed >>>>> Community Coordination Group, which would prioritize issues identified >>>>> by the community and build solutions for those issues. As proposed by >>>>> staff, this group is too heavily controlled by the ICANN board and staff >>>>> and as such it replicates the problem of ICANN?s accountability >>>>> structures being circular and lacking independence. Given the >>>>> overwhelming number of public comments submitted supporting the need for >>>>> an independent accountability mechanisms, it is unclear on what basis >>>>> ICANN staff proposed a solution in which the ICANN board and staff would >>>>> fill a large number of the seats on the CCG. It is also unclear on what >>>>> basis staff thinks board-picked advisors should have an equal voice as >>>>> representatives of community members. Outside experts are welcome and >>>>> can provide valuable input, but they should be selected by and report to >>>>> the community, not the board or staff for independent accountability to >>>>> be achieved. And advisors? role must be clarified as an informational >>>>> role, rather than a decision making role that representatives of >>>>> stakeholder interests would hold in a bottom-up process. It is also >>>>> necessary that the role of any ICANN board or staff on this CCG serve in >>>>> a non-decision making, support or liaison function. For the CCG to >>>>> have legitimacy as a participatory form of democracy, the >>>>> decision-making members must consist of stakeholders, not the ICANN >>>>> board and staff. The make-up, roles and responsibilities of the members >>>>> of the proposed CCG must be reformulated in a more bottom-up fashion by >>>>> the community for this proposal to be acceptable. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> PC-NCSG mailing list >>>>> PC-NCSG at ipjustice.org >>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>> >>>>> >>>>> _______________________________________________ >>>>> PC-NCSG mailing list >>>>> PC-NCSG at ipjustice.org >>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>> >>>>> >>>>> _______________________________________________ >>>>> PC-NCSG mailing list >>>>> PC-NCSG at ipjustice.org >>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>>> >>>>> _______________________________________________ >>>>> PC-NCSG mailing list >>>>> PC-NCSG at ipjustice.org >>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>>> >>>> >>>> _______________________________________________ >>>> PC-NCSG mailing list >>>> PC-NCSG at ipjustice.org >>>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > From robin Tue Aug 12 19:56:13 2014 From: robin (Robin Gross) Date: Tue, 12 Aug 2014 09:56:13 -0700 Subject: [PC-NCSG] Letter to send In-Reply-To: References: <53E9875F.7060201@acm.org> Message-ID: <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> So we are waiting another five hours (end of business day in US)? I thought this was going to be sent a couple times already. Robin On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: > Hi Avri, > > if we don't hear in the next 5 hours any objections (And we didn't see any before), we can assume the statement reached consensus and can be sent. I will wait and proceed after that deadline. > thanks for sharing the final and clean version. > > Best, > > Rafik > > 2014-08-12 12:17 GMT+09:00 Avri Doria : > I suggest that Rafik send this version. I added Ron's edit, sort of, to > Cintra's version.at this point i think that a note saying we need more > time to comment seems to have been overcome by events. but i don't > really care, if singing it makes us seem more together with the other > SGs, so be it. > > And sure I support endorsing the RySG stmt. > But why since we have our own. > > > > > avri > > ----- > > > NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 > > The NCSG appreciates this opportunity to provide feedback regarding the > ICANN Staff?s non-stakeholder led proposal for further work on > ?Enhancing Accountability? at ICANN. > > A number of public comments and discussions in London focused on the > inherent conflict of interest behind staff developing its own > accountability and transparency mechanisms, so it was surprising to see > that input had not been taken into account in the development of this > proposal. NCSG notes its disappointment with the staff having skipped > the step of providing a synthesis of the community feedback received > from the ICANN public comments forum and the London accountability > discussions. Over a month ago, staff assured it was working on this > during GNSO Council and SO/AC leadership calls since the London meeting; > normally, staff can produce a synthesis of a comment period within a > week, so we are at a loss to explain this delay. > > NCSG reiterates its request to see the synthesis of public input upon > which staff relied in the formulation of its accountability proposal. > It is impossible to know where the components of staff?s proposal come > from and on what basis they are called for, without being privy to > staff?s assessment of the public input on the subject. It is difficult > to find those elements in the written comments to effectively evaluate > the proposal. > > At a time when the world is indeed watching ICANN to discern if it can > be trusted without NTIA oversight of its global governance functions, > and is particularly interested in the formulation of a proposal for > resolving ICANN?s accountability crisis; to skip the step of providing > the rationale for staff?s proposal, including its basis in the > community?s stakeholder comments, seems imprudent at best. From its > inception, the community should have been engaged in the formulation of > the proposal, not pressured into signing-off on a staff proposal at the > 11th hour. This is an example of top-down policymaking, which runs > counter to ICANN?s bottom-up methodology and may inspire mistrust on the > part of the stakeholders. > > Regarding the substance of the staff proposal, the NCSG does not support > it as currently drafted. Of particular concern is the proposed > Community Coordination Group (CCG), which would prioritize issues > identified by the community and build solutions for those issues. As > proposed by staff, this group is too heavily controlled by the ICANN > board and staff and as such it replicates the problem of ICANN?s > accountability structures being circular and lacking independence. > > We reiterate that given the overwhelming number of public comments > submitted supporting the need for an independent accountability > mechanisms, it is unclear on what basis ICANN staff proposed a solution > in which the ICANN board and staff would fill a large number of the > seats on the CCG. It is also unclear on what basis staff thinks > board-picked advisors should have an equal voice as representatives of > community members. Outside experts are welcome and can provide valuable > input, but they should be selected by and report to the community not > the board or staff, for independent accountability to be achieved. > > An advisor's role must be clarified as an informational role, as only > representatives of stakeholder interests in a bottom-up process hold > decision making roles. It is also necessary that the role of any ICANN > board or staff on this CCG serve in a non-decision making, support or > liaison function. For the CCG to have legitimacy as a participatory > form of democracy, the decision-making members must consist of > stakeholders, not the ICANN board and staff. The make-up, roles and > responsibilities of the members of the proposed CCG must be reformulated > in a more bottom-up fashion by the community for this proposal to be > acceptable. > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stephanie.perrin Tue Aug 12 20:35:29 2014 From: stephanie.perrin (Stephanie Perrin) Date: Tue, 12 Aug 2014 13:35:29 -0400 Subject: [PC-NCSG] Letter to send In-Reply-To: <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> References: <53E9875F.7060201@acm.org> <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> Message-ID: <53EA5061.90209@mail.utoronto.ca> We seem to need a better process for this folks...maybe a template with due dates/hours, that travels with the document (like a change document on a report)? if you have not commented by 24 hours before the deadline, the door shuts... something like that. It is not really fair to the owner of the document, and to Rafik and Maria to demand they stand on their heads all day waiting for a final final final to clear all the gates. just a thought, I realize we are all busy but I know from recent experience on the WHOIS conflicts document that this is difficult and needs to be more clear. cheers Stephanie On 14-08-12 12:56 PM, Robin Gross wrote: > So we are waiting another five hours (end of business day in US)? I > thought this was going to be sent a couple times already. > > Robin > > > On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: > >> Hi Avri, >> >> if we don't hear in the next 5 hours any objections (And we didn't >> see any before), we can assume the statement reached consensus and >> can be sent. I will wait and proceed after that deadline. >> thanks for sharing the final and clean version. >> >> Best, >> >> Rafik >> >> 2014-08-12 12:17 GMT+09:00 Avri Doria > >: >> >> I suggest that Rafik send this version. I added Ron's edit, sort >> of, to >> Cintra's version.at this point i think that >> a note saying we need more >> time to comment seems to have been overcome by events. but i don't >> really care, if singing it makes us seem more together with the other >> SGs, so be it. >> >> And sure I support endorsing the RySG stmt. >> But why since we have our own. >> >> >> >> >> avri >> >> ----- >> >> >> NCSG Statement on ICANN Staff's Accountability Plan, 11 Aug 2014 >> >> The NCSG appreciates this opportunity to provide feedback >> regarding the >> ICANN Staff's non-stakeholder led proposal for further work on >> "Enhancing Accountability" at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising >> to see >> that input had not been taken into account in the development of this >> proposal. NCSG notes its disappointment with the staff having skipped >> the step of providing a synthesis of the community feedback received >> from the ICANN public comments forum and the London accountability >> discussions. Over a month ago, staff assured it was working on this >> during GNSO Council and SO/AC leadership calls since the London >> meeting; >> normally, staff can produce a synthesis of a comment period within a >> week, so we are at a loss to explain this delay. >> >> NCSG reiterates its request to see the synthesis of public input upon >> which staff relied in the formulation of its accountability proposal. >> It is impossible to know where the components of staff's proposal >> come >> from and on what basis they are called for, without being privy to >> staff's assessment of the public input on the subject. It is >> difficult >> to find those elements in the written comments to effectively >> evaluate >> the proposal. >> >> At a time when the world is indeed watching ICANN to discern if >> it can >> be trusted without NTIA oversight of its global governance functions, >> and is particularly interested in the formulation of a proposal for >> resolving ICANN's accountability crisis; to skip the step of >> providing >> the rationale for staff's proposal, including its basis in the >> community's stakeholder comments, seems imprudent at best. From its >> inception, the community should have been engaged in the >> formulation of >> the proposal, not pressured into signing-off on a staff proposal >> at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN's bottom-up methodology and may inspire mistrust >> on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not >> support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group (CCG), which would prioritize issues >> identified by the community and build solutions for those issues. As >> proposed by staff, this group is too heavily controlled by the ICANN >> board and staff and as such it replicates the problem of ICANN's >> accountability structures being circular and lacking independence. >> >> We reiterate that given the overwhelming number of public comments >> submitted supporting the need for an independent accountability >> mechanisms, it is unclear on what basis ICANN staff proposed a >> solution >> in which the ICANN board and staff would fill a large number of the >> seats on the CCG. It is also unclear on what basis staff thinks >> board-picked advisors should have an equal voice as >> representatives of >> community members. Outside experts are welcome and can provide >> valuable >> input, but they should be selected by and report to the community not >> the board or staff, for independent accountability to be achieved. >> >> An advisor's role must be clarified as an informational role, as only >> representatives of stakeholder interests in a bottom-up process hold >> decision making roles. It is also necessary that the role of any >> ICANN >> board or staff on this CCG serve in a non-decision making, support or >> liaison function. For the CCG to have legitimacy as a participatory >> form of democracy, the decision-making members must consist of >> stakeholders, not the ICANN board and staff. The make-up, roles and >> responsibilities of the members of the proposed CCG must be >> reformulated >> in a more bottom-up fashion by the community for this proposal to be >> acceptable. >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Tue Aug 12 23:47:47 2014 From: rafik.dammak (Rafik Dammak) Date: Wed, 13 Aug 2014 05:47:47 +0900 Subject: [PC-NCSG] Letter to send In-Reply-To: <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> References: <53E9875F.7060201@acm.org> <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> Message-ID: Hi Robin, I sent the letter, I waited as much as possible Rafik 2014-08-13 1:56 GMT+09:00 Robin Gross : > So we are waiting another five hours (end of business day in US)? I > thought this was going to be sent a couple times already. > > Robin > > > > On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: > > Hi Avri, > > if we don't hear in the next 5 hours any objections (And we didn't see any > before), we can assume the statement reached consensus and can be sent. I > will wait and proceed after that deadline. > thanks for sharing the final and clean version. > > Best, > > Rafik > > 2014-08-12 12:17 GMT+09:00 Avri Doria : > >> I suggest that Rafik send this version. I added Ron's edit, sort of, to >> Cintra's version.at this point i think that a note saying we need more >> time to comment seems to have been overcome by events. but i don't >> really care, if singing it makes us seem more together with the other >> SGs, so be it. >> >> And sure I support endorsing the RySG stmt. >> But why since we have our own. >> >> >> >> >> avri >> >> ----- >> >> >> NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 >> >> The NCSG appreciates this opportunity to provide feedback regarding the >> ICANN Staff?s non-stakeholder led proposal for further work on >> ?Enhancing Accountability? at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising to see >> that input had not been taken into account in the development of this >> proposal. NCSG notes its disappointment with the staff having skipped >> the step of providing a synthesis of the community feedback received >> from the ICANN public comments forum and the London accountability >> discussions. Over a month ago, staff assured it was working on this >> during GNSO Council and SO/AC leadership calls since the London meeting; >> normally, staff can produce a synthesis of a comment period within a >> week, so we are at a loss to explain this delay. >> >> NCSG reiterates its request to see the synthesis of public input upon >> which staff relied in the formulation of its accountability proposal. >> It is impossible to know where the components of staff?s proposal come >> from and on what basis they are called for, without being privy to >> staff?s assessment of the public input on the subject. It is difficult >> to find those elements in the written comments to effectively evaluate >> the proposal. >> >> At a time when the world is indeed watching ICANN to discern if it can >> be trusted without NTIA oversight of its global governance functions, >> and is particularly interested in the formulation of a proposal for >> resolving ICANN?s accountability crisis; to skip the step of providing >> the rationale for staff?s proposal, including its basis in the >> community?s stakeholder comments, seems imprudent at best. From its >> inception, the community should have been engaged in the formulation of >> the proposal, not pressured into signing-off on a staff proposal at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group (CCG), which would prioritize issues >> identified by the community and build solutions for those issues. As >> proposed by staff, this group is too heavily controlled by the ICANN >> board and staff and as such it replicates the problem of ICANN?s >> accountability structures being circular and lacking independence. >> >> We reiterate that given the overwhelming number of public comments >> submitted supporting the need for an independent accountability >> mechanisms, it is unclear on what basis ICANN staff proposed a solution >> in which the ICANN board and staff would fill a large number of the >> seats on the CCG. It is also unclear on what basis staff thinks >> board-picked advisors should have an equal voice as representatives of >> community members. Outside experts are welcome and can provide valuable >> input, but they should be selected by and report to the community not >> the board or staff, for independent accountability to be achieved. >> >> An advisor's role must be clarified as an informational role, as only >> representatives of stakeholder interests in a bottom-up process hold >> decision making roles. It is also necessary that the role of any ICANN >> board or staff on this CCG serve in a non-decision making, support or >> liaison function. For the CCG to have legitimacy as a participatory >> form of democracy, the decision-making members must consist of >> stakeholders, not the ICANN board and staff. The make-up, roles and >> responsibilities of the members of the proposed CCG must be reformulated >> in a more bottom-up fashion by the community for this proposal to be >> acceptable. >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin Tue Aug 12 23:59:49 2014 From: robin (Robin Gross) Date: Tue, 12 Aug 2014 13:59:49 -0700 Subject: [PC-NCSG] Letter to send In-Reply-To: References: <53E9875F.7060201@acm.org> <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> Message-ID: <1FCB1EBF-34DE-4E5C-8F9C-AA174FDF6D7C@ipjustice.org> Thank you, Rafik! Would you please send a copy of the final draft that was submitted so I can post it online? Or if you've already posted it online somewhere, just send the link to it then. Thanks again, Robin On Aug 12, 2014, at 1:47 PM, Rafik Dammak wrote: > Hi Robin, > > I sent the letter, I waited as much as possible > > Rafik > > > 2014-08-13 1:56 GMT+09:00 Robin Gross : > So we are waiting another five hours (end of business day in US)? I thought this was going to be sent a couple times already. > > Robin > > > > On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: > >> Hi Avri, >> >> if we don't hear in the next 5 hours any objections (And we didn't see any before), we can assume the statement reached consensus and can be sent. I will wait and proceed after that deadline. >> thanks for sharing the final and clean version. >> >> Best, >> >> Rafik >> >> 2014-08-12 12:17 GMT+09:00 Avri Doria : >> I suggest that Rafik send this version. I added Ron's edit, sort of, to >> Cintra's version.at this point i think that a note saying we need more >> time to comment seems to have been overcome by events. but i don't >> really care, if singing it makes us seem more together with the other >> SGs, so be it. >> >> And sure I support endorsing the RySG stmt. >> But why since we have our own. >> >> >> >> >> avri >> >> ----- >> >> >> NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 >> >> The NCSG appreciates this opportunity to provide feedback regarding the >> ICANN Staff?s non-stakeholder led proposal for further work on >> ?Enhancing Accountability? at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising to see >> that input had not been taken into account in the development of this >> proposal. NCSG notes its disappointment with the staff having skipped >> the step of providing a synthesis of the community feedback received >> from the ICANN public comments forum and the London accountability >> discussions. Over a month ago, staff assured it was working on this >> during GNSO Council and SO/AC leadership calls since the London meeting; >> normally, staff can produce a synthesis of a comment period within a >> week, so we are at a loss to explain this delay. >> >> NCSG reiterates its request to see the synthesis of public input upon >> which staff relied in the formulation of its accountability proposal. >> It is impossible to know where the components of staff?s proposal come >> from and on what basis they are called for, without being privy to >> staff?s assessment of the public input on the subject. It is difficult >> to find those elements in the written comments to effectively evaluate >> the proposal. >> >> At a time when the world is indeed watching ICANN to discern if it can >> be trusted without NTIA oversight of its global governance functions, >> and is particularly interested in the formulation of a proposal for >> resolving ICANN?s accountability crisis; to skip the step of providing >> the rationale for staff?s proposal, including its basis in the >> community?s stakeholder comments, seems imprudent at best. From its >> inception, the community should have been engaged in the formulation of >> the proposal, not pressured into signing-off on a staff proposal at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group (CCG), which would prioritize issues >> identified by the community and build solutions for those issues. As >> proposed by staff, this group is too heavily controlled by the ICANN >> board and staff and as such it replicates the problem of ICANN?s >> accountability structures being circular and lacking independence. >> >> We reiterate that given the overwhelming number of public comments >> submitted supporting the need for an independent accountability >> mechanisms, it is unclear on what basis ICANN staff proposed a solution >> in which the ICANN board and staff would fill a large number of the >> seats on the CCG. It is also unclear on what basis staff thinks >> board-picked advisors should have an equal voice as representatives of >> community members. Outside experts are welcome and can provide valuable >> input, but they should be selected by and report to the community not >> the board or staff, for independent accountability to be achieved. >> >> An advisor's role must be clarified as an informational role, as only >> representatives of stakeholder interests in a bottom-up process hold >> decision making roles. It is also necessary that the role of any ICANN >> board or staff on this CCG serve in a non-decision making, support or >> liaison function. For the CCG to have legitimacy as a participatory >> form of democracy, the decision-making members must consist of >> stakeholders, not the ICANN board and staff. The make-up, roles and >> responsibilities of the members of the proposed CCG must be reformulated >> in a more bottom-up fashion by the community for this proposal to be >> acceptable. >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rafik.dammak Wed Aug 13 00:10:08 2014 From: rafik.dammak (Rafik Dammak) Date: Wed, 13 Aug 2014 06:10:08 +0900 Subject: [PC-NCSG] Letter to send In-Reply-To: <1FCB1EBF-34DE-4E5C-8F9C-AA174FDF6D7C@ipjustice.org> References: <53E9875F.7060201@acm.org> <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> <1FCB1EBF-34DE-4E5C-8F9C-AA174FDF6D7C@ipjustice.org> Message-ID: it is posted here https://community.icann.org/pages/viewpage.action?pageId=48350198 / https://community.icann.org/x/9sPhAg Rafik 2014-08-13 5:59 GMT+09:00 Robin Gross : > Thank you, Rafik! Would you please send a copy of the final draft that > was submitted so I can post it online? Or if you've already posted it > online somewhere, just send the link to it then. > > Thanks again, > Robin > > > > On Aug 12, 2014, at 1:47 PM, Rafik Dammak wrote: > > Hi Robin, > > I sent the letter, I waited as much as possible > > Rafik > > > 2014-08-13 1:56 GMT+09:00 Robin Gross : > >> So we are waiting another five hours (end of business day in US)? I >> thought this was going to be sent a couple times already. >> >> Robin >> >> >> >> On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: >> >> Hi Avri, >> >> if we don't hear in the next 5 hours any objections (And we didn't see >> any before), we can assume the statement reached consensus and can be sent. >> I will wait and proceed after that deadline. >> thanks for sharing the final and clean version. >> >> Best, >> >> Rafik >> >> 2014-08-12 12:17 GMT+09:00 Avri Doria : >> >>> I suggest that Rafik send this version. I added Ron's edit, sort of, to >>> Cintra's version.at this point i think that a note saying we need more >>> time to comment seems to have been overcome by events. but i don't >>> really care, if singing it makes us seem more together with the other >>> SGs, so be it. >>> >>> And sure I support endorsing the RySG stmt. >>> But why since we have our own. >>> >>> >>> >>> >>> avri >>> >>> ----- >>> >>> >>> NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 >>> >>> The NCSG appreciates this opportunity to provide feedback regarding the >>> ICANN Staff?s non-stakeholder led proposal for further work on >>> ?Enhancing Accountability? at ICANN. >>> >>> A number of public comments and discussions in London focused on the >>> inherent conflict of interest behind staff developing its own >>> accountability and transparency mechanisms, so it was surprising to see >>> that input had not been taken into account in the development of this >>> proposal. NCSG notes its disappointment with the staff having skipped >>> the step of providing a synthesis of the community feedback received >>> from the ICANN public comments forum and the London accountability >>> discussions. Over a month ago, staff assured it was working on this >>> during GNSO Council and SO/AC leadership calls since the London meeting; >>> normally, staff can produce a synthesis of a comment period within a >>> week, so we are at a loss to explain this delay. >>> >>> NCSG reiterates its request to see the synthesis of public input upon >>> which staff relied in the formulation of its accountability proposal. >>> It is impossible to know where the components of staff?s proposal come >>> from and on what basis they are called for, without being privy to >>> staff?s assessment of the public input on the subject. It is difficult >>> to find those elements in the written comments to effectively evaluate >>> the proposal. >>> >>> At a time when the world is indeed watching ICANN to discern if it can >>> be trusted without NTIA oversight of its global governance functions, >>> and is particularly interested in the formulation of a proposal for >>> resolving ICANN?s accountability crisis; to skip the step of providing >>> the rationale for staff?s proposal, including its basis in the >>> community?s stakeholder comments, seems imprudent at best. From its >>> inception, the community should have been engaged in the formulation of >>> the proposal, not pressured into signing-off on a staff proposal at the >>> 11th hour. This is an example of top-down policymaking, which runs >>> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >>> part of the stakeholders. >>> >>> Regarding the substance of the staff proposal, the NCSG does not support >>> it as currently drafted. Of particular concern is the proposed >>> Community Coordination Group (CCG), which would prioritize issues >>> identified by the community and build solutions for those issues. As >>> proposed by staff, this group is too heavily controlled by the ICANN >>> board and staff and as such it replicates the problem of ICANN?s >>> accountability structures being circular and lacking independence. >>> >>> We reiterate that given the overwhelming number of public comments >>> submitted supporting the need for an independent accountability >>> mechanisms, it is unclear on what basis ICANN staff proposed a solution >>> in which the ICANN board and staff would fill a large number of the >>> seats on the CCG. It is also unclear on what basis staff thinks >>> board-picked advisors should have an equal voice as representatives of >>> community members. Outside experts are welcome and can provide valuable >>> input, but they should be selected by and report to the community not >>> the board or staff, for independent accountability to be achieved. >>> >>> An advisor's role must be clarified as an informational role, as only >>> representatives of stakeholder interests in a bottom-up process hold >>> decision making roles. It is also necessary that the role of any ICANN >>> board or staff on this CCG serve in a non-decision making, support or >>> liaison function. For the CCG to have legitimacy as a participatory >>> form of democracy, the decision-making members must consist of >>> stakeholders, not the ICANN board and staff. The make-up, roles and >>> responsibilities of the members of the proposed CCG must be reformulated >>> in a more bottom-up fashion by the community for this proposal to be >>> acceptable. >>> >>> >>> _______________________________________________ >>> PC-NCSG mailing list >>> PC-NCSG at ipjustice.org >>> http://mailman.ipjustice.org/listinfo/pc-ncsg >>> >>> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Thu Aug 14 03:43:30 2014 From: rafik.dammak (Rafik Dammak) Date: Thu, 14 Aug 2014 09:43:30 +0900 Subject: [PC-NCSG] Letter to send In-Reply-To: <53EA5061.90209@mail.utoronto.ca> References: <53E9875F.7060201@acm.org> <2477CA40-207A-4CDE-9F9E-E3BDA5AAA580@ipjustice.org> <53EA5061.90209@mail.utoronto.ca> Message-ID: Hi Stephanie, thanks for raising this, I think you are mentioning 2 case but different aspects: - for the last statement, it comes with short notice and we needed to act quickly. there was no real way to predict. the question here is we need to setup a fast-track process for endorsing for those sudden cases and how to deal with them in timely manner. - for the whois comment, we knew we had to make it and we were looking for for a volunteer to draft etc. I am thinking we need more sustainable way to respond to statement: setting up ad-hoc group like privacy and for transparency to handle any public comment coming. preparing a draft more earlier to allow people to comment and that will lessen somehow the stress to get things done near to deadline. members of WGs will help to notify PC and membership about coming reports and comments too. I will try to send reminders about open comments too and we should discuss about priority since we cannot cover everything. we can add more solid process as you suggested but I would like to use collaborative document to prevent the nightmare of versioning. The PC chair can declare the timeline when receiving the draft till the final decision. it will be of course documented for reference, there are also some practices to encourage like asking people to suggest specific wording when making comments, that make things more easy for editing etc saying that, we still need the PC members to be more reactive and responsive. I will be glad to hear their feedback and point of view in this matter and what they think can be done time for brainstorming and finding solutions :) Rafik ps as a former liaison for CSISAC, do you think basecamp was useful, what practices were helpful? 2014-08-13 2:35 GMT+09:00 Stephanie Perrin < stephanie.perrin at mail.utoronto.ca>: > We seem to need a better process for this folks...maybe a template with > due dates/hours, that travels with the document (like a change document on > a report)? if you have not commented by 24 hours before the deadline, the > door shuts... something like that. It is not really fair to the owner of > the document, and to Rafik and Maria to demand they stand on their heads > all day waiting for a final final final to clear all the gates. > just a thought, I realize we are all busy but I know from recent > experience on the WHOIS conflicts document that this is difficult and needs > to be more clear. > cheers Stephanie > > On 14-08-12 12:56 PM, Robin Gross wrote: > > So we are waiting another five hours (end of business day in US)? I > thought this was going to be sent a couple times already. > > Robin > > > On Aug 12, 2014, at 12:08 AM, Rafik Dammak wrote: > > Hi Avri, > > if we don't hear in the next 5 hours any objections (And we didn't see > any before), we can assume the statement reached consensus and can be sent. > I will wait and proceed after that deadline. > thanks for sharing the final and clean version. > > Best, > > Rafik > > 2014-08-12 12:17 GMT+09:00 Avri Doria : > >> I suggest that Rafik send this version. I added Ron's edit, sort of, to >> Cintra's version.at this point i think that a note saying we need more >> time to comment seems to have been overcome by events. but i don't >> really care, if singing it makes us seem more together with the other >> SGs, so be it. >> >> And sure I support endorsing the RySG stmt. >> But why since we have our own. >> >> >> >> >> avri >> >> ----- >> >> >> NCSG Statement on ICANN Staff?s Accountability Plan, 11 Aug 2014 >> >> The NCSG appreciates this opportunity to provide feedback regarding the >> ICANN Staff?s non-stakeholder led proposal for further work on >> ?Enhancing Accountability? at ICANN. >> >> A number of public comments and discussions in London focused on the >> inherent conflict of interest behind staff developing its own >> accountability and transparency mechanisms, so it was surprising to see >> that input had not been taken into account in the development of this >> proposal. NCSG notes its disappointment with the staff having skipped >> the step of providing a synthesis of the community feedback received >> from the ICANN public comments forum and the London accountability >> discussions. Over a month ago, staff assured it was working on this >> during GNSO Council and SO/AC leadership calls since the London meeting; >> normally, staff can produce a synthesis of a comment period within a >> week, so we are at a loss to explain this delay. >> >> NCSG reiterates its request to see the synthesis of public input upon >> which staff relied in the formulation of its accountability proposal. >> It is impossible to know where the components of staff?s proposal come >> from and on what basis they are called for, without being privy to >> staff?s assessment of the public input on the subject. It is difficult >> to find those elements in the written comments to effectively evaluate >> the proposal. >> >> At a time when the world is indeed watching ICANN to discern if it can >> be trusted without NTIA oversight of its global governance functions, >> and is particularly interested in the formulation of a proposal for >> resolving ICANN?s accountability crisis; to skip the step of providing >> the rationale for staff?s proposal, including its basis in the >> community?s stakeholder comments, seems imprudent at best. From its >> inception, the community should have been engaged in the formulation of >> the proposal, not pressured into signing-off on a staff proposal at the >> 11th hour. This is an example of top-down policymaking, which runs >> counter to ICANN?s bottom-up methodology and may inspire mistrust on the >> part of the stakeholders. >> >> Regarding the substance of the staff proposal, the NCSG does not support >> it as currently drafted. Of particular concern is the proposed >> Community Coordination Group (CCG), which would prioritize issues >> identified by the community and build solutions for those issues. As >> proposed by staff, this group is too heavily controlled by the ICANN >> board and staff and as such it replicates the problem of ICANN?s >> accountability structures being circular and lacking independence. >> >> We reiterate that given the overwhelming number of public comments >> submitted supporting the need for an independent accountability >> mechanisms, it is unclear on what basis ICANN staff proposed a solution >> in which the ICANN board and staff would fill a large number of the >> seats on the CCG. It is also unclear on what basis staff thinks >> board-picked advisors should have an equal voice as representatives of >> community members. Outside experts are welcome and can provide valuable >> input, but they should be selected by and report to the community not >> the board or staff, for independent accountability to be achieved. >> >> An advisor's role must be clarified as an informational role, as only >> representatives of stakeholder interests in a bottom-up process hold >> decision making roles. It is also necessary that the role of any ICANN >> board or staff on this CCG serve in a non-decision making, support or >> liaison function. For the CCG to have legitimacy as a participatory >> form of democracy, the decision-making members must consist of >> stakeholders, not the ICANN board and staff. The make-up, roles and >> responsibilities of the members of the proposed CCG must be reformulated >> in a more bottom-up fashion by the community for this proposal to be >> acceptable. >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg >> >> > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > > > > _______________________________________________ > PC-NCSG mailing listPC-NCSG at ipjustice.orghttp://mailman.ipjustice.org/listinfo/pc-ncsg > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Fri Aug 15 03:19:21 2014 From: rafik.dammak (Rafik Dammak) Date: Fri, 15 Aug 2014 09:19:21 +0900 Subject: [PC-NCSG] [account-icann] ICANN Staff response to accountability statements Message-ID: Hi everyone, below the response from Theresa to our statement and the Registries and BC statement. the latest proposal will be posted soon too and what I can say is that we need to be ready for commenting it. it should be the first task for the ad-hoc group we set-up. Best, Rafik ---------- Forwarded message ---------- From: Theresa Swinehart <> Date: 2014-08-14 11:00 GMT+09:00 Subject: Re: Joint RySG and BC Position Statement on ICANN Staff's Proposed Accountability Process To: Dear Rafik, Keith, Elisa, and Tony Thank you for all of your thoughtful additional input to the accountability process. As I also shared in a note last week, we have already considered further revisions to the accountability process based on the feedback received on the draft shared on the SO/AC/SG call last week. The revised process ? along with a summary and analysis of the public comments focused on process ? will be posted this week. The summary and analysis is focused on the process, not the substantive input received on accountability topics and proposed solutions; those inputs will be addressed through the process. As you can imagine there is a wide range of interest in the accountability process both within the ICANN community and outside the community. This is a critical inflection point for all stakeholders within ICANN ? including ICANN itself. The accountability process and looking at whether any additional accountability mechanisms are needed in light of the changing historical relationship with the US is a process of interest to the ICANN community and far beyond the ICANN community. It would be premature (and not for ICANN staff) to pre-determine the outcome of the process, and whether for example one of the outcomes may be the establishment of the independent accountability mechanism as called for in the GNSO joint statement in London. This is for the process to address together with the other substantive issues and solutions identified by the community. It is this broader view of the goals and possibilities of this work that ICANN is relying on in building the accountability process. Just as there is a very important role for all ICANN stakeholders in this conversation, there is also a need to ensure there?s acceptance outside the immediate ICANN community. Thus the approach must allow for variations of existing models, complemented by identifying external expertise to enable this process to reach conclusions that are acceptable both within the ICANN community and outside the ICANN community. In the ICANN multistakeholder model, the range of interests well outside the community are as equally relevant to this process as the immediate ICANN community. The multistakeholder ICANN Community is not separate and apart from the ICANN entity. The cross community working group called for in your letter may be independent of ICANN staff or Board, but it is not independent from ICANN. We appreciated the concern about ICANN staff or Board identifying up to 7 advisors to the coordination group and have modified this to ensure the appointments are not done that way. We look forward to discussing the revised process on the call on the 14 August. As one small addition, I noted the reference to the GNSO?s policy development process in Keith and Elisa?s note. While there is always the possibility that some of this accountability work may result in items that need to be referred to a PDP, this accountability process is not a PDP. There has been substantial time available for discussion of the accountability process which began in May, ending in June, including the ICANN 50 meeting. ICANN will post the process shortly after sharing it with the SO/AC/SG leadership on 14 August ? ICANN has a responsibility to be responsive to the community as a whole to allow this process to move forward. The work ahead is going to be challenging, and we trust that you will bring the enthusiasm you bring to the process design to the accountability work itself. Kind regards, Theresa -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Tue Aug 26 15:05:12 2014 From: rafik.dammak (Rafik Dammak) Date: Tue, 26 Aug 2014 21:05:12 +0900 Subject: [PC-NCSG] Fwd: [NCSG-Discuss] DIDP Proposal / Bylaws Change In-Reply-To: References: Message-ID: Hi everyone, that was requested for NCSG PC consideration. Best, Rafik ---------- Forwarded message ---------- From: Edward Morris Date: 2014-08-26 20:58 GMT+09:00 Subject: [NCSG-Discuss] DIDP Proposal / Bylaws Change To: NCSG-DISCUSS at listserv.syr.edu Hi, Public comments are now open for a proposal to change the threshold the Board needs to act contrary to GAC advice from it?s current simple majority to a 2/3 vote ( https://www.icann.org/public-comments/bylaws-amend-gac-advice-2014-08-15-en ). There has been considerable discussion about this issue on the NCUC list during which I suggested we might want to do a DIDP in order to become fully informed about the impetus for this change. This proposal has received some support. The goals of the DIDP are two fold: 1. To learn more about the dynamics that has led to this proposal. Is there resistance on the Board? That would be useful to know as we plan our response. 2. I?m hopeful that this may be the first DIDP in recent history to actually result in the release of documents. As I demonstrate in the attached draft, the usual reasons cited by staff for refusing to give requested information ? the DCND ? do not apply in this instance. If, despite this, staff refuses to give us any additional information on matters concerning a change in the Bylaws, the most serious of all issues, it strengthens our case that current transparency rules should in no way be confused with the FOIA standards suggested in the Thune / Rubio letter. Our call for greater transparency in ICANN would be strengthened. I?d like to ask members of the NCSG PC to please take a look at the attached DIDP draft, make changes as necessary and decide whether or not to proceed with this approach. Time is of the essence. ICANN has 30 days to respond to this DIDP Request once filed and the Reply Period for the proposed Bylaws change ends on October 6th. It would be nice to get a response from ICANN prior to the close of the Reply Period so we as a community and as individuals can comment on the basis of what we receive, if anything. Thanks, Ed P.S. To those on the NCUC list my apology for the cross post. As Avri astutely suggested, if I?m asking for support of the NCSG PC the draft should be posted on the SG list. Now it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: anewdip.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml Size: 125007 bytes Desc: not available URL: From stephanie.perrin Tue Aug 26 16:30:02 2014 From: stephanie.perrin (Stephanie Perrin) Date: Tue, 26 Aug 2014 09:30:02 -0400 Subject: [PC-NCSG] Fwd: [NCSG-Discuss] DIDP Proposal / Bylaws Change In-Reply-To: References: Message-ID: <53FC8BDA.2070206@mail.utoronto.ca> Thanks for doing this Ed, this is great! I could become a real enthusiast of this process!!! Having been a FOIA coordinator here in Canada, I have reacted like a bureaucrat and suggested a few word changes in the attached markup version...some for clarity, and some because I can imagine documents which in fact might fit in some of the categories, which the GAC could have in their possession, and could have submitted to the Board. I think we need, on a separate note, to be pushing for independent oversight of such requests, through the Ombudsman. You don't have that in the US, but in Canada we have independent Information Commissioners who review exemption decisions (among many other things). That would be a good thing, as the Board appears to have some accountability issues, possibly statutory in nature, that make their review of staff decisions on these matters problematic. Great job! Stephanie Perrin On 14-08-26 8:05 AM, Rafik Dammak wrote: > Hi everyone, > > that was requested for NCSG PC consideration. > > Best, > > Rafik > ---------- Forwarded message ---------- > From: *Edward Morris* > > Date: 2014-08-26 20:58 GMT+09:00 > Subject: [NCSG-Discuss] DIDP Proposal / Bylaws Change > To: NCSG-DISCUSS at listserv.syr.edu > > > Hi, > Public comments are now open for a proposal to change the threshold > the Board needs to act contrary to GAC advice from it's current simple > majority to a 2/3 vote > (https://www.icann.org/public-comments/bylaws-amend-gac-advice-2014-08-15-en > ). There has been considerable discussion about this issue on the NCUC > list during which I suggested we might want to do a DIDP in order to > become fully informed about the impetus for this change. This proposal > has received some support. > The goals of the DIDP are two fold: > 1. To learn more about the dynamics that has led to this proposal. Is > there resistance on the Board? That would be useful to know as we plan > our response. > 2. I'm hopeful that this may be the first DIDP in recent history to > actually result in the release of documents. As I demonstrate in the > attached draft, the usual reasons cited by staff for refusing to give > requested information -- the DCND -- do not apply in this instance. > If, despite this, staff refuses to give us any additional information > on matters concerning a change in the Bylaws, the most serious of all > issues, it strengthens our case that current transparency rules should > in no way be confused with the FOIA standards suggested in the Thune / > Rubio letter. Our call for greater transparency in ICANN would be > strengthened. > I'd like to ask members of the NCSG PC to please take a look at the > attached DIDP draft, make changes as necessary and decide whether or > not to proceed with this approach. Time is of the essence. ICANN has > 30 days to respond to this DIDP Request once filed and the Reply > Period for the proposed Bylaws change ends on October 6th. It would be > nice to get a response from ICANN prior to the close of the Reply > Period so we as a community and as individuals can comment on the > basis of what we receive, if anything. > Thanks, > Ed > P.S. To those on the NCUC list my apology for the cross post. As Avri > astutely suggested, if I'm asking for support of the NCSG PC the draft > should be posted on the SG list. Now it is. > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: anewdipsp.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 129826 bytes Desc: not available URL: From aelsadr Tue Aug 26 21:45:10 2014 From: aelsadr (Amr Elsadr) Date: Tue, 26 Aug 2014 20:45:10 +0200 Subject: [PC-NCSG] [NCSG-Discuss] Fwd: [NCSG-Discuss] DIDP Proposal / Bylaws Change In-Reply-To: <53FC8BDA.2070206@mail.utoronto.ca> References: <53FC8BDA.2070206@mail.utoronto.ca> Message-ID: <23CC0F8C-934A-42ED-84A2-09FC10879A0C@egyptig.org> Hi, Thanks for the draft and revision Ed and Stephanie. I am certainly in favour of submitting this. The more information we have on the context of this proposed amendment to the by-laws, the more informed we will be on submitting feedback to the proposal. I would like to (grudgingly) note that according to the ICANN by-laws, all that is required to amend those very by-laws is a 2/3 vote by the board in favour. I don?t even think that a public comment period is mandatory. I?m not entirely sure about this, but this requirement isn't explicitly made clear in the by-laws or even the articles of incorporation. This would change if ICANN became a membership-based organisation (not that I am saying this is a good thing as I haven?t really thought out the ramifications). I suspect that this will come to a board vote, and when it does, I hope there is so much push-back from the community; enough to have the required number of board members vote against the amendment. Thanks. Amr On Aug 26, 2014, at 3:30 PM, Stephanie Perrin wrote: > Thanks for doing this Ed, this is great! I could become a real enthusiast of this process!!! Having been a FOIA coordinator here in Canada, I have reacted like a bureaucrat and suggested a few word changes in the attached markup version...some for clarity, and some because I can imagine documents which in fact might fit in some of the categories, which the GAC could have in their possession, and could have submitted to the Board. > I think we need, on a separate note, to be pushing for independent oversight of such requests, through the Ombudsman. You don't have that in the US, but in Canada we have independent Information Commissioners who review exemption decisions (among many other things). That would be a good thing, as the Board appears to have some accountability issues, possibly statutory in nature, that make their review of staff decisions on these matters problematic. > Great job! > Stephanie Perrin > On 14-08-26 8:05 AM, Rafik Dammak wrote: >> Hi everyone, >> >> that was requested for NCSG PC consideration. >> >> Best, >> >> Rafik >> ---------- Forwarded message ---------- >> From: Edward Morris >> Date: 2014-08-26 20:58 GMT+09:00 >> Subject: [NCSG-Discuss] DIDP Proposal / Bylaws Change >> To: NCSG-DISCUSS at listserv.syr.edu >> >> >> Hi, >> >> Public comments are now open for a proposal to change the threshold the Board needs to act contrary to GAC advice from it?s current simple majority to a 2/3 vote ( https://www.icann.org/public-comments/bylaws-amend-gac-advice-2014-08-15-en ). There has been considerable discussion about this issue on the NCUC list during which I suggested we might want to do a DIDP in order to become fully informed about the impetus for this change. This proposal has received some support. >> >> The goals of the DIDP are two fold: >> >> 1. To learn more about the dynamics that has led to this proposal. Is there resistance on the Board? That would be useful to know as we plan our response. >> >> 2. I?m hopeful that this may be the first DIDP in recent history to actually result in the release of documents. As I demonstrate in the attached draft, the usual reasons cited by staff for refusing to give requested information ? the DCND ? do not apply in this instance. >> >> If, despite this, staff refuses to give us any additional information on matters concerning a change in the Bylaws, the most serious of all issues, it strengthens our case that current transparency rules should in no way be confused with the FOIA standards suggested in the Thune / Rubio letter. Our call for greater transparency in ICANN would be strengthened. >> >> I?d like to ask members of the NCSG PC to please take a look at the attached DIDP draft, make changes as necessary and decide whether or not to proceed with this approach. Time is of the essence. ICANN has 30 days to respond to this DIDP Request once filed and the Reply Period for the proposed Bylaws change ends on October 6th. It would be nice to get a response from ICANN prior to the close of the Reply Period so we as a community and as individuals can comment on the basis of what we receive, if anything. >> >> Thanks, >> >> Ed >> >> P.S. To those on the NCUC list my apology for the cross post. As Avri astutely suggested, if I?m asking for support of the NCSG PC the draft should be posted on the SG list. Now it is. >> >> >> >> _______________________________________________ >> PC-NCSG mailing list >> PC-NCSG at ipjustice.org >> http://mailman.ipjustice.org/listinfo/pc-ncsg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Wed Aug 27 14:59:59 2014 From: rafik.dammak (Rafik Dammak) Date: Wed, 27 Aug 2014 20:59:59 +0900 Subject: [PC-NCSG] Cross community letter regarding ICANN's Accountability Process Announcement Message-ID: Hi Everyone, there was discussion between leaders of SOs/ACs regarding letter to ICANN CEO and the board about the proposal for accountability process. I copied the letter below. I am submitting it for review from NCSG PC and getting membership feedback. I would like that we act swiftly about it. personally, I advise to sign it at least as community reaction and request for clarifying details left behind and not covered in the faq. but I want also to get any additional proposal or comments I can share with the chairs of other groups. Best Regards, Rafik Fadi Chehad?, CEO, ICANN Dr. Stephen Crocker, Chair, ICANN Board of Directors ICANN Board of Directors Dear Fadi, Steve and ICANN Directors, Regarding ICANN?s announcement on August 14, 2014, Enhancing Accountability: Process and Next Steps , the Supporting Organisation, Advisory Committee, Stakeholder Group and Constituency chairs formally request additional time and opportunity to review and discuss the proposal contained in the announcement and in the subsequent FAQ?s published on August 22, so that next steps can be confirmed with increased support from the ICANN community. Recognizing that the ICANN plan is a brand new construct that was announced without a corresponding public comment period, substantial questions and concerns remain unanswered, including around the process to date and the plan as constructed. The undersigned Supporting Organisation, Advisory Committee, Stakeholder Group and Constituency leaders are currently engaging our respective groups? bottom-up, consensus processes at this time to develop and finalize a list of questions that will require clarification or correction. As a result, additional opportunity is needed to ensure understanding of the proposal and the ways in which it is responsive to the interests and working methods of the ICANN stakeholder groups. We commit to submitting to ICANN staff our list of clarifying questions and comments within seven days of this letter. Since the Enhancing Accountability process will affect ICANN?s future, as well as the range of stakeholders impacted by its decisions, we trust that this request will be received positively and lead to further engagement on this important matter to ensure that the SOs, ACs and SGs and Cs not only understand the proposed approach, but are able to endorse it. Signed, -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Wed Aug 27 15:15:53 2014 From: avri (Avri Doria) Date: Wed, 27 Aug 2014 15:15:53 +0300 Subject: [PC-NCSG] Cross community letter regarding ICANN's Accountability Process Announcement In-Reply-To: References: Message-ID: <53FDCBF9.1070300@acm.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, As i just said on the Discuss list, I am against signing the letter as it just contributes to delay. If there is something we want them to change or fix. lets craft a letter that says that. avri On 27-Aug-14 14:59, Rafik Dammak wrote: > Hi Everyone, > > there was discussion between leaders of SOs/ACs regarding letter to > ICANN CEO and the board about the proposal for accountability > process. I copied the letter below. I am submitting it for review > from NCSG PC and getting membership feedback. I would like that we > act swiftly about it. > > personally, I advise to sign it at least as community reaction and > request for clarifying details left behind and not covered in the > faq. but I want also to get any additional proposal or comments I > can share with the chairs of other groups. > > Best Regards, > > Rafik > > > > > > Fadi Chehad?, CEO, ICANN > > Dr. Stephen Crocker, Chair, ICANN Board of Directors > > ICANN Board of Directors > > > > Dear Fadi, Steve and ICANN Directors, > > > > Regarding ICANN?s announcement on August 14, 2014, Enhancing > Accountability: Process and Next Steps > , > > the Supporting Organisation, Advisory Committee, Stakeholder Group and > Constituency chairs formally request additional time and > opportunity to review and discuss the proposal contained in the > announcement and in the subsequent FAQ?s > > > published on August 22, so that next steps can be confirmed with increased > support from the ICANN community. > > > > Recognizing that the ICANN plan is a brand new construct that was > announced without a corresponding public comment period, > substantial questions and concerns remain unanswered, including > around the process to date and the plan as constructed. > > > > The undersigned Supporting Organisation, Advisory Committee, > Stakeholder Group and Constituency leaders are currently engaging > our respective groups? bottom-up, consensus processes at this time > to develop and finalize a list of questions that will require > clarification or correction. As a result, additional opportunity > is needed to ensure understanding of the proposal and the ways in > which it is responsive to the interests and working methods of the > ICANN stakeholder groups. We commit to submitting to ICANN staff > our list of clarifying questions and comments within seven days of > this letter. > > > > Since the Enhancing Accountability process will affect ICANN?s > future, as well as the range of stakeholders impacted by its > decisions, we trust that this request will be received positively > and lead to further engagement on this important matter to ensure > that the SOs, ACs and SGs and Cs not only understand the proposed > approach, but are able to endorse it. > > > > Signed, > > > > _______________________________________________ PC-NCSG mailing > list PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/cv5AAoJEOo+L8tCe36Hll0H/3UvVkNrLCl/4iO9CN3qBJEd JTsaM+UeKXjjIEYwZSGR8+mysCUGIJYEB1fHcCGbxfkxoAH4AY90R10OMBwpCNs3 4v/g04oRwd6/xcflu/QaDv/jk3sHgo34KxjQkyDmkonHo8Sd42cKRJOknoL4lrRA aMM0iUw1wk8cdqkE+USfjaa061S1URl/favzH0xDNpAwrKOh/f5jXZDK0mjsvgg8 11+HymVyM51H8T9fuChk/Nn50Y0Rr22SGGbQhp5GlcbL3NHqR7DFL58Z1HG/OyY1 N7mhPCxtooYD0iv8p1jvmsAG/G6XdvQANF6uQDIQUWrMcyUPi9o9yME+Xg28S2E= =EPWM -----END PGP SIGNATURE----- From joy Wed Aug 27 15:47:55 2014 From: joy (joy) Date: Thu, 28 Aug 2014 00:47:55 +1200 Subject: [PC-NCSG] Cross community letter regarding ICANN's Accountability Process Announcement In-Reply-To: <53FDCBF9.1070300@acm.org> References: <53FDCBF9.1070300@acm.org> Message-ID: <53FDD37B.1070206@apc.org> An HTML attachment was scrubbed... URL: From aelsadr Wed Aug 27 17:09:18 2014 From: aelsadr (Amr Elsadr) Date: Wed, 27 Aug 2014 16:09:18 +0200 Subject: [PC-NCSG] [NCSG-Discuss] Cross community letter regarding ICANN's Accountability Process Announcement In-Reply-To: <53FDCBAA.9020702@acm.org> References: <53FDCBAA.9020702@acm.org> Message-ID: Hi, There?s a number of things about this process that stink to me including the PEG?s selection of advisors to join the Coordination Group and the Board drafting the charter for both the Cross Community Group and Coordination Group (not sure how that second one happened), but I agree with Avri. IMHO, the draft letter doesn?t present a very compelling reason to delay this process. If answers to questions not already provided by the announcement and FAQs are needed, then sure?, by all means the community should ask the questions, and board/staff should provide answers. But what does that have to do with when the process starts? If there are more specific objections the community wants addressed before the process starts, then the letter should specifically say so. Otherwise, we should encourage the process to go ahead and get started, and like Avri said: On Aug 27, 2014, at 2:14 PM, Avri Doria wrote: > Otherwise I think we should get on with: > > 1. signing up for the community group and starting to demand to see a > draft charter we can mark up. > > 2. figuring out who we want to represent NCSG on the coordination group. I appreciate that there is considerable level of frustration amongst the SOs/ACs, but I can?t think of a reason why postponement with the intent of getting answers to as yet undefined questions will alleviate those concerns. I?m not saying that there should be an urgency to start this very questionable (to say the least) process that supersedes every concern, but if we will ask for a delay, it should be for a better reason than the one provided. I don?t think this letter quite does that. Thanks. Amr -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Thu Aug 28 17:15:18 2014 From: rafik.dammak (Rafik Dammak) Date: Thu, 28 Aug 2014 23:15:18 +0900 Subject: [PC-NCSG] [Input] Feedback Request: Policy & Implementation Working Group (PIWG) Message-ID: Hi everyone, I received request for NCSG input for the ongoing work in the Policy & Implementation Working group. if some of you may recall correctly , Avri gave us a heads-up weeks ago sharing some documents. you will find attached charts of new processes under discussion, aimed to improve the work of GNSO. it will be helpful to get some explanation and briefing from the NCSg members of that working group and getting a volunteer to collect comments to draft a NCSG input. Thanks, Best Regard, Rafik ---------- Forwarded message ---------- From: Glen de Saint G?ry Date: 2014-08-28 0:33 GMT+09:00 Subject: Feedback Request: Policy & Implementation Working Group (PIWG) To: Dear Rafik, One of the questions that the Policy & Implementation Working Group (PIWG) was tasked to consider is: ?Under what circumstances, if any, may the GNSO Council make recommendations or state positions to the Board on matters of policy and implementation as a representative of the GNSO as a whole?? In consideration of this question, the PIWG is currently developing possible recommendations for new processes in addition to the existing Policy Development Process (PDP) by which the GNSO Council can provide input on behalf of the GNSO community on policy and related questions brought to its attention by the ICANN Board, other ICANN Supporting Organizations and/or Advisory Committees (SO/ACs) and by GNSO participants. As these proposed mechanisms are likely to be of great interest to the GNSO community, the PIWG would very much like to seek your group?s feedback on the attached flow charts outlining these potential processes. We have not yet developed detailed descriptions of these processes so we are not looking for feedback at that level (although that would be accepted) but rather, we would like to know whether or not you think we are headed in a constructive direction in considering new processes like these. Attached are flow charts that show the two additional processes: a proposed GNSO Guidance Process (GGP) and a proposed GNSO Input Process (GIP). They are intended to supplement the existing mechanisms by which the GNSO Council performs its work and manages that of the GNSO community. The processes are intended to add to the flexibility and responsiveness of the GNSO and the Council. They represent our attempt to balance the need for such nimbleness with the need for codified processes that will allow the GNSO and the Council to deal with requests other than on an ad-hoc basis. The possibility of a ?fast track? PDP is also included in some of the flow charts to try to address situations where policies already adopted by the ICANN Board may need clarification or updating. The flow charts are organized as follows: 1. An overview of the GNSO Process Options including the new processes 2. An outline of the GNSO Guidance Process (GGP) without a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, the same as required to initiate a PDP; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council 3. An outline of the GNSO Guidance Process (GGP) with a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, supermajority as currently defined for the GNSO Council; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council 4. An outline of the GNSO Input Process (GIP). Note that flowcharts 2, 3 & 4 contain boxes that are colored in orange. These indicate that those are specific areas that the WG will further review and discuss once a more detailed description of these processes is available. If you already have any specific input you would like to provide on these areas (or any other), you are more than welcome to do so, but please note that there will of course be further opportunities to provide input as further details are developed by the WG. The PIWG will be grateful if your group could provide its feedback to us by Friday 12 September 2014. At a minimum we would like to know whether you think the PIWG is heading in the right direction with regard to its consideration of recommending two new processes similar to the GGP and GIP shown in the flowcharts. In addition, feedback would also be welcome at your option regarding the orange colored boxes in the flow charts. We will be happy to address any questions that your members may have in the meantime. Your questions and your feedback may be provided via your WG representative(s) or via email in response to this message. Best regards, J. Scott Evans & Chuck Gomes (Co-Chairs), Michael Graham & Olevie Kouami (Co-Vice-Chairs) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GNSO Processes - updated 18 August 2014.pdf Type: application/pdf Size: 243249 bytes Desc: not available URL: From aelsadr Thu Aug 28 18:50:23 2014 From: aelsadr (Amr Elsadr) Date: Thu, 28 Aug 2014 17:50:23 +0200 Subject: [PC-NCSG] [NCSG-Discuss] [Input] Feedback Request: Policy & Implementation Working Group (PIWG) In-Reply-To: References: Message-ID: <8469AD35-D134-420D-8C97-28717704598E@egyptig.org> Hi, Thanks for passing this along Rafik. I am willing to draft a response based on discussions that take place on this list. I hope folks could take some time to look at the document attached to Rafik?s email. It contains four flowcharts; one that would help determine when on of four processes would be used for the GNSO to provide input to policy discussions, then the other three illustrating three of the processes leaving out the already existing PDP. These are meant to be frameworks for processes that will help the GNSO address situations where formal and long PDPs are not necessarily required. They are not the final product of the WG, but the WG members think it would be a good idea to get input from the various GNSO SGs/Cs before proceeding further. I?d be happy to answer any questions too. Just take a look and share your thoughts. We do have a number of NCSG members who are on the WG and some who were also involved in the charter drafting. Input from them would be great, but it would also be extremely valuable to hear from others too. Also, it may be worth mentioning that this is not really a working group of a combative nature with conflicting interests between different stakeholders. All the WG members are working together to try to figure out detailed processes (frameworks and criteria) that can be agreed to by all to help the GNSO function more efficiently. Thanks. Amr On Aug 28, 2014, at 4:15 PM, Rafik Dammak wrote: > Hi everyone, > > I received request for NCSG input for the ongoing work in the Policy & Implementation Working group. if some of you may recall correctly , Avri gave us a heads-up weeks ago sharing some documents. you will find attached charts of new processes under discussion, aimed to improve the work of GNSO. > it will be helpful to get some explanation and briefing from the NCSg members of that working group and getting a volunteer to collect comments to draft a NCSG input. > > Thanks, > > Best Regard, > > Rafik > > > ---------- Forwarded message ---------- > From: Glen de Saint G?ry > Date: 2014-08-28 0:33 GMT+09:00 > Subject: Feedback Request: Policy & Implementation Working Group (PIWG) > To: > > > > > > > > Dear Rafik, > > > > One of the questions that the Policy & Implementation Working Group (PIWG) was tasked to consider is: ?Under what circumstances, if any, may the GNSO Council make recommendations or state positions to the Board on matters of policy and implementation as a representative of the GNSO as a whole?? In consideration of this question, the PIWG is currently developing possible recommendations for new processes in addition to the existing Policy Development Process (PDP) by which the GNSO Council can provide input on behalf of the GNSO community on policy and related questions brought to its attention by the ICANN Board, other ICANN Supporting Organizations and/or Advisory Committees (SO/ACs) and by GNSO participants. As these proposed mechanisms are likely to be of great interest to the GNSO community, the PIWG would very much like to seek your group?s feedback on the attached flow charts outlining these potential processes. We have not yet developed detailed descriptions of these processes so we are not looking for feedback at that level (although that would be accepted) but rather, we would like to know whether or not you think we are headed in a constructive direction in considering new processes like these. > > > > Attached are flow charts that show the two additional processes: a proposed GNSO Guidance Process (GGP) and a proposed GNSO Input Process (GIP). They are intended to supplement the existing mechanisms by which the GNSO Council performs its work and manages that of the GNSO community. The processes are intended to add to the flexibility and responsiveness of the GNSO and the Council. They represent our attempt to balance the need for such nimbleness with the need for codified processes that will allow the GNSO and the Council to deal with requests other than on an ad-hoc basis. The possibility of a ?fast track? PDP is also included in some of the flow charts to try to address situations where policies already adopted by the ICANN Board may need clarification or updating. > > > > The flow charts are organized as follows: > > 1. An overview of the GNSO Process Options including the new processes > > 2. An outline of the GNSO Guidance Process (GGP) without a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, the same as required to initiate a PDP; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council > > 3. An outline of the GNSO Guidance Process (GGP) with a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, supermajority as currently defined for the GNSO Council; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council > > 4. An outline of the GNSO Input Process (GIP). > > > > Note that flowcharts 2, 3 & 4 contain boxes that are colored in orange. These indicate that those are specific areas that the WG will further review and discuss once a more detailed description of these processes is available. If you already have any specific input you would like to provide on these areas (or any other), you are more than welcome to do so, but please note that there will of course be further opportunities to provide input as further details are developed by the WG. > > > > The PIWG will be grateful if your group could provide its feedback to us by Friday 12 September 2014. At a minimum we would like to know whether you think the PIWG is heading in the right direction with regard to its consideration of recommending two new processes similar to the GGP and GIP shown in the flowcharts. In addition, feedback would also be welcome at your option regarding the orange colored boxes in the flow charts. > > > > We will be happy to address any questions that your members may have in the meantime. Your questions and your feedback may be provided via your WG representative(s) or via email in response to this message. > > > > Best regards, > > > > J. Scott Evans & Chuck Gomes (Co-Chairs), Michael Graham & Olevie Kouami (Co-Vice-Chairs) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Sat Aug 30 06:43:19 2014 From: avri (Avri Doria) Date: Sat, 30 Aug 2014 06:43:19 +0300 Subject: [PC-NCSG] reconsideration request Message-ID: <54014857.9090109@acm.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see that a reconsideration request has been filled with the NCSG listed as requester, signed by Steve DelBianco of the Business Constituency. https://www.icann.org/en/system/files/files/request-bc-rysg-ncsg-29aug14-en.pdf Was NCSG listed with NCSG permission? If so, when did the NCSG-PC approve this? Or have we gotten to the point that we no longer bother getting approval for such things? I may be the only one who objects to this, especially since it is made on flawed ground, but I do not remember any consensus calls on the issue Seems somewhat ironic that we are complaining about the process infractions of others when we no longer seem to care about about NCSG processes. No matter what the merits of the case, the fact that this was submitted in the NCSG's name without an NCSG decision to do so, is of great concern. In so far as we may or may not have formal procedures that we are using, I object to this action and request of review of what process was followed in our decision to participate and clarification as to who made the decision? If on the other hand it was submitted in our name without authorization, then I request that an amendment to the request be filed indicating that there was no authorization for the NCSG to be listed on the reconsideration request. avri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAUhXAAoJEOo+L8tCe36HdxUIAItGdnWFq0sjx+CksgabeW2f dYsF8RgWu22Q+MeQmK+ssx3mMkRCitvcAuujjfgFZ0hH0JrUaZs4QBy0EdjwlYkl SmIRpl4WzsVfd7k1a/keeGeuiIQaK4Vw+GodqhqCc2KamR2lqLs9FQm2D29qUTRT tAXS4c4C7pYnaEScqoXUOXOdG33axPw6QZY9xt4bFvFO8OA0llBBTSSpJIIyTpn9 H5X/hDl9VceCQiIwmPslhUAW5KKo28pqhYaFEG60SjcYkgCbwbXIBmNZQDlTposu pbXvAdYY+UQwUF8FM/MB7Ige1R1Pp9UGWLXSf9TPx85tnZT9/QP7wryP69Sm5bs= =7BFL -----END PGP SIGNATURE----- From aelsadr Sat Aug 30 12:45:08 2014 From: aelsadr (Amr Elsadr) Date: Sat, 30 Aug 2014 11:45:08 +0200 Subject: [PC-NCSG] [NCSG-Discuss] reconsideration request In-Reply-To: <8097773488887102434@unknownmsgid> References: <8097773488887102434@unknownmsgid> Message-ID: Hi, On Aug 30, 2014, at 10:29 AM, Remmy Nweke wrote: > Thanks Segun and Avri > I think Rafik has given enough explanation on issues raised its either we accept his explanation or suggest more better was of mitigation now and in the future. > Or better still call for consensus/vote where time permits. I completely agree. For what it?s worth, I?m happy to endorse this RR after-the-fact. I believe that, as opposed to the joint SO/AC letter draft previously circulated, that this RR was a lot more specific in its reasons, which seem pretty justifiable to me. Although the accountability process isn?t specifically a policy on gTLD policy, it is still very much reflective of ICANN staff and board decision-making. The By-Laws are as clear on ICANN?s requirement to be transparent and inclusive of its community on one as the other. I do, however, recognise that the NCSG decision-making process wasn?t followed. The way I see it (and others may disagree) is that on of the NCSG PC duties included in our charter stating: ?Discussion and development of substantive policies and statements issued in the name of the NCSG. This activity will require coordination with the membership and the Constituencies? ?, includes statements that represent the NCSG, which are not specific to the work of the GNSO Council. Still?, I do believe that our Chair did act in good faith when deciding to sign off on the RR on behalf of the NCSG. Considering the time restraint he had to deal with and what I perceive to be a rough estimation of general sentiment expressed on this list, I believe he acted not on his own behalf, but on how he perceived the NCSG membership would have wished him to act. I don?t imagine it?s easy being in that position, and I appreciate Rafik?s willingness to act in the way he thought was best for the SG. > Can't we request for extended time even by a week to put our house position in order? Not that I can tell, Remmy. The process for submitting RRs is limited to a 15-day period following the staff or board action (check here: https://www.icann.org/resources/pages/reconsideration-2012-02-25-en). Thanks. Amr -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephanie.perrin Sat Aug 30 15:52:46 2014 From: stephanie.perrin (Stephanie Perrin) Date: Sat, 30 Aug 2014 08:52:46 -0400 Subject: [PC-NCSG] [NCSG-Discuss] reconsideration request In-Reply-To: References: <8097773488887102434@unknownmsgid> Message-ID: <5401C91E.9010906@mail.utoronto.ca> Me too, and I thought we had discussed this enough. Frankly, being Chair is a thankless job. Let's try to be as supportive as possible. Thanks everyone Stephanie On 2014-08-30, 5:45, Amr Elsadr wrote: > Hi, > > On Aug 30, 2014, at 10:29 AM, Remmy Nweke > wrote: > >> Thanks Segun and Avri >> I think Rafik has given enough explanation on issues raised its >> either we accept his explanation or suggest more better was of >> mitigation now and in the future. >> Or better still call for consensus/vote where time permits. > > I completely agree. For what it's worth, I'm happy to endorse this RR > after-the-fact. I believe that, as opposed to the joint SO/AC letter > draft previously circulated, that this RR was a lot more specific in > its reasons, which seem pretty justifiable to me. Although the > accountability process isn't specifically a policy on gTLD policy, it > is still very much reflective of ICANN staff and board > decision-making. The By-Laws are as clear on ICANN's requirement to be > transparent and inclusive of its community on one as the other. > > I do, however, recognise that the NCSG decision-making process wasn't > followed. The way I see it (and others may disagree) is that on of the > NCSG PC duties included in our charter stating: > / > / > *"/Discussion and development of substantive policies and statements > issued in the name of the NCSG. This activity will require > coordination with the membership and the Constituencies"/* > > ..., includes statements that represent the NCSG, which are not > specific to the work of the GNSO Council. > > Still..., I do believe that our Chair did act in good faith when > deciding to sign off on the RR on behalf of the NCSG. Considering the > time restraint he had to deal with and what I perceive to be a rough > estimation of general sentiment expressed on this list, I believe he > acted not on his own behalf, but on how he perceived the NCSG > membership would have wished him to act. I don't imagine it's easy > being in that position, and I appreciate Rafik's willingness to act in > the way he thought was best for the SG. > >> Can't we request for extended time even by a week to put our house >> position in order? > > Not that I can tell, Remmy. The process for submitting RRs is limited > to a 15-day period following the staff or board action (check here: > https://www.icann.org/resources/pages/reconsideration-2012-02-25-en). > > Thanks. > > Amr > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak Sun Aug 31 08:04:50 2014 From: rafik.dammak (Rafik Dammak) Date: Sun, 31 Aug 2014 14:04:50 +0900 Subject: [PC-NCSG] starting process of appointment to Accountabilit and Governance co-ordination group Message-ID: Hi everyone, With regard to the announcement about the accountability process. the policy committee should start the process of appointment of representative from NCSG to the coordination coordination group, preferably before the 15th September. https://www.icann.org/resources/pages/enhancing-accountability-faqs-2014-08-22-en#10 "*10. How can I participate in the Coordination Group?* The SO/AC/SGs will identify the expert candidates from their respective communities to be appointed to the Coordination Group, who will then be confirmed by the Cross Community Group. These names should be provided to the Cross Community Group and be public. Names selected by the SO/AC/SGs for the Coordination Group are encouraged to be submitted to the Cross Community Group prior to its 15 September meeting. One does not need to be a member of the Cross Community Group to be selected by the respectiveSO/AC/SGs to the Coordination Group. SO/AC/SGs may identify their own processes for selecting experts. All participants on the Coordination Group are expected to conduct the work on a consensus basis, consistent with community processes, including open, transparent, and meeting with the community at respectiveICANN meetings." so we should setup quickly a process (timeline, list of criteria) and call for candidature, hopefully within this week. @Maria can you please initiate and lead this? Thanks. Best Regards, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From avri Sun Aug 31 08:35:29 2014 From: avri (Avri Doria) Date: Sun, 31 Aug 2014 08:35:29 +0300 Subject: [PC-NCSG] starting process of appointment to Accountabilit and Governance co-ordination group In-Reply-To: References: Message-ID: <5402B421.3070309@acm.org> Hi, How about call for nominations on the discussion list - with a requirements that they have signed up for the community group And then the PC picks - with any PC members who may have been nominated abstaining from the process. avri On 31-Aug-14 08:04, Rafik Dammak wrote: > Hi everyone, > > With regard to the announcement about the accountability process. > the policy committee should start the process of appointment of > representative from NCSG to the coordination coordination group, preferably > before the 15th September. > > https://www.icann.org/resources/pages/enhancing-accountability-faqs-2014-08-22-en#10 > > "*10. How can I participate in the Coordination Group?* > The SO/AC/SGs will identify the expert candidates from their respective > communities to be appointed to the Coordination Group, who will then be > confirmed by the Cross Community Group. These names should be provided to > the Cross Community Group and be public. Names selected by the SO/AC/SGs > for the Coordination Group are encouraged to be submitted to the Cross > Community Group prior to its 15 September meeting. One does not need to be > a member of the Cross Community Group to be selected by the respectiveSO/AC/SGs > to the Coordination Group. SO/AC/SGs may identify their own processes for > selecting experts. All participants on the Coordination Group are expected > to conduct the work on a consensus basis, consistent with community > processes, including open, transparent, and meeting with the community at > respectiveICANN meetings." > > so we should setup quickly a process (timeline, list of criteria) and call > for candidature, hopefully within this week. > @Maria can you please initiate and lead this? > Thanks. > > Best Regards, > > Rafik > > > > _______________________________________________ > PC-NCSG mailing list > PC-NCSG at ipjustice.org > http://mailman.ipjustice.org/listinfo/pc-ncsg >