April 2009 - council - lists.icann.org

GNSO Council draft minutes 19 February 2009
by Glen de Saint Géry April 14, 2009

April 14, 2009

Dear Council members, Attached, please find the draft Council minutes for the teleconference held on 19 February 2009. Let me know if you would like any changes made. Thank you. Kind regards, Glen Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

RE: [council] Motion on next round of IRTP issues to address
by Tim Ruiz April 14, 2009

April 14, 2009

Makes sense. Accepted as friendly. Tim -------- Original Message -------- Subject: RE: [council] Motion on next round of IRTP issues to address From: "Gomes, Chuck" <cgomes(a)verisign.com> Date: Tue, April 14, 2009 1:46 pm To: "Tim Ruiz" <tim(a)godaddy.com>, "GNSO Council " <council(a)gnso.icann.org> Tim, I would like to request what I think is a friendly amendment to this motion. Change the intro to the resolve section: From: "Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO Council initiate the formal GNSO Policy Development Process by requesting the creation of an issues report on the following issues:" To: "Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO Council requests the creation of an issues report on the following issues:" The previous wording was accurate, but I am concerned that it could easily be misunderstood to mean that we are initiating a PDP. As you know, we are only requesting an issues report and once the issues report is complete, we will decide whether to initiate a PDP. My rewording is simply intended to avoid any confusion in this regard. Chuck > -----Original Message----- > From: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz > Sent: Wednesday, April 08, 2009 12:10 PM > To: GNSO Council > Subject: [council] Motion on next round of IRTP issues to address > > The IRTP Working Group has considered the issues contained in > Part B and Part C for possible inclusion in the next round of > work on the remaining IRTP issues. As a result, they have > asked that I present the following motion (below in text, and > attached in a Word doc): > > Tim > > WHEREAS, > The Inter-Registrar Transfer Policy (IRTP) is an existing > consensus policy under review by the GNSO, > > A GNSO group of volunteers assigned five PDP groupings to 19 > identified IRTP issues, based on a previously developed > prioritized issues list, > > Three additional issues were added to IRTP C based on > recommendations from the IRTP Denial Definitions WG and the > Issues Report on Post-Expiration Domain Name Recovery, > > The IRTP Part A WG has recommended combining the issues > outlined under PDP B and some of the issues outlined under > PDP C into one PDP B in order to be more efficient and > hopefully reduce the overall timeline for addressing all the > IRTP PDPs, > > The GNSO Council retains the option to address the issues > outlined below in one PDP or two separate PDPs following the > completion of the issues report, > > RESOLVED, > Pursuant to section 1.b of Annex A of ICANN's Bylaws, that > the GNSO Council initiate the formal GNSO Policy Development > Process by requesting the creation of an issues report on the > following issues: > > a) Whether a process for urgent return/resolution of a domain name > should be developed, as discussed within the SSAC hijacking > report > (http://www.icann.org/announcements/hijacking-report-12jul05.p > df; see also > http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm) > (Issue #2) > b) Whether additional provisions on undoing inappropriate > transfers are > needed, especially with regard to disputes between a > Registrant and Admin Contact. The policy is clear that the > Registrant can overrule the AC, but how this is implemented > is currently at the discretion of the registrar. (Issue #7) > c) Whether special provisions are needed for a change of > registrant near > a change of registrar. The policy does not currently deal > with change of registrant, which often figures in hijacking > cases. (Issue #9) > d) Whether standards or best practices should be > implemented regarding > use of Registrar Lock status (e.g., when it may/may not, > should/should not be applied). (Issue #5) > e) Whether, and if so, how best to clarify denial reason > #7: A domain > name was already in "lock status" provided that the Registrar > provides a readily accessible and reasonable means for the > Registered Name Holder to remove the lock status. > (Recommendation from the IRTP Denials WG) > > (Note: The issue numbers included above refer to the original > numbering in the Transfers Working Group list.) > >

1 0

Thursday's council meeting
by Avri Doria April 14, 2009

April 14, 2009

Hi, Just wanted to let the council know that I will be late i dialing in to the meeting this week. While the schedule exercise was going on for both of my meetings, I did not realize they were going to collide. Once I realized it, it was too late to change either one. As the other meeting is a status report meeting on my EU funded research project, I really need to attend. Chuck will start out chairing the meeting. Once I manage to join, I will be able to take the chair on the next agenda item, assuming that is the right thing to do. Apologies and Thanks a.

1 0

Action Item from 26 March Meeting elated to RAA amendments
by Avri Doria April 14, 2009

April 14, 2009

Hi, Apologies for getting to this one this late before the meeting. Re; Item 6 Registrar Accreditation Agreement (RAA) Motion Action Items from March 26 > Avri proposed writing a description of the group's mission which would > clarify the issue, submitting that to the Council list for discussion, > and then commence with one drafting group, leaving open the option to > split into two groups if needed. The Board is scheduled to vote on the council's motion on the RAA amaendments on 23 April. In the meantime we still need to get the WGs going. There were two proposed in our motion: > agreed to convene two groups of representatives from the GNSO > Community within 30 days of Board approval to: 1) draft a registrant > rights charter; and 2) identify further amendments to the RAA on which > further action may be desirable and provide its advice to the Council > and ICANN staff no later than 31 July 2009. > At our last meeting there was a suggestion that we should start with 1 WG and then create a second if required. I offered to start the ball rolling by writing up a description of the proposed charter items for a WG that could initiate the discussions. ---- 1. Registrar community to produce a list of existing registrant rights (this was already mentioned at the last meeting) 2. WG to define a mechanism by which the community can be brought into the discussion of the rights identified by the Registrars and recommend means to the GNSO council by which these can be used to develop a registrant rights charter. 3. WG to define specific areas in which further amendments to the RAA could be developed. 4. WG to engage in consultation with the ICANN legal staff to differentiate between prospective amendment areas that could be made via a PDP process and those prospective amendment areas that would require a negotiation, or other, process. 5. WG to make a set of proposals, to be vetted among the constituencies and in a community public comment, on requested issues reports and on other processes to be initiated. A Final Proposal, including appropriate response to public comment, should be available for review by the council no later then 31 July 2009. ---- The charter items should be discussed by a drafting team on the list created for this WG and incorporated into the a charter following the process currently being used by other GNSO WGs and following the interim WG methods. The charter should be brought to the GNSO council for a vote at its next meeting. At that time a council liaison to the group could be approved and a chair can be confirmed. a.

1 0

Motion on Whois Service requirements activity
by Avri Doria April 14, 2009

April 14, 2009

Hi, After a conversation with some of the staff about this motion and the work it involves, it became obvious I should amend the motion based on work load and work priorities. I am changing: The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and should be ready for community discussion in time for the Sydney meeting. to: The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and a strawman proposal should be prepared for these consultations. The Staff is asked to come back with an estimate of when this would be possible. Chuck, who has seconded the motion, accepts the amendment as well. thanks a.

2 2

Travel funds needed for Sydney
by Olga Cavalli April 13, 2009

April 13, 2009

Hi, as background information for our next confrence call in relation with travel funds needed for Sydney, these are the answers recieved from constituencies: - ISPCP needs support for three reps and supports the use of DNSO residue funds. - NCUC intends to use its remaining slot and would need additional funding to ensure fuller non-commercial participation in Sydney. They support the use of residual DNSO funds. - IPC intends to use the 3.5 travel supported slots, and may wish to have additional support to facilitate presentations and discussion on the IRT output. They support the use of residual DNSO funds. - BC requires travel support for all three reps. They use of DNSO residue funds. - RyC requests full travel funding for one person to attend and participate in the ICANN Sydney meetings in June 2009. For the funding associated with the remaining three slots allocated to the RyC for the current fiscal year, the RyC recommends any FY09 travel funds allocated to the RyC left over at the end of June be rolled over to FY10 for use by the RyC for future travel needs for GNSO activities. Regarding the use of DNSO funds still remaining on ICANN books, the RyC believes that a good use of those funds for the benefit of the whole community in the long term would be to use them for improving the capacity for remote participation in an effective manner and thereby minimizes the heavy dependence on in-person participation. We believe that this would scale much better and be a much more fiscally responsible approach over the longer term than continuing to try to subsidize travel expenses for what likely will be a growing need of GNSO participants in the future. In relation with this feedback I have updated our table for travel funds: *Updated table of travel funds for GNSO Council* *Total Available* *Remaining for* *Requested for Sydney* *Remaining* *Constituencies* *Per Year* *Sydney* * * * * NCUC 5 1 0,5+0,5=1 0 ISPC 5 1 2,5 -1,5 RyC 5 4 1 3 BC 5 1 3 -2 RrC 5 2 2 0 IPC 5 3.5 - - *Total* *30* *12.5* * 9,5* *-3,5 + 3* The previous version of the table was: *Updated table of travel funds for GNSO Council* *Cairo* *Mexico City* *Total per* *Total Available* *Remaining for* *Constituencies* *Meeting* *Meeting* *Constituency* *Per Year* *Sydney* NCUC 2 2 4 5 1 ISPC 1 3 4 5 1 RyC 1 0 1 5 4 BC 3 1 4 5 1 RrC 1 2 3 5 2 IPC 0.5 1 1.5 5 3.5 *Total* *8.5* *9* *17.5* *30* *12.5* Regards to all. Olga

1 0

FYI - Notice of Intent to Form New GNSO Constituency - The IDN TLD Constituency
by Robert Hoggarth April 11, 2009

April 11, 2009

Dear GNSO Council Members; For your information, attached please find a copy of the Notice of Intent to Form a New GNSO Constituency (NOIF) submitted yesterday by Dr. S. Subbiah, Chairman of i-DNS.net, Inc. proposing to form the new IDN TLD Constituency. The document has been posted on the GNSO Improvements web page at http://gnso.icann.org/en/improvements/newco-process-en.htm. Best regards, Rob Hoggarth Robert L. Hoggarth, Esq. Senior Policy Director ICANN 424 558 4805 robert.hoggarth(a)icann.org

1 0

Olga Cavalli updated statement of Interest and ccNSO observer
by Glen de Saint Géry April 10, 2009

April 10, 2009

Dear Council members, Please note that Olga Cavalli has updated her statement of interest. http://gnso.icann.org/council/soi/cavalli-soi-09april09.shtml Mr. Han Chuan Lee from the .sg registry has been appointed as the ccNSO Council Observer to the GNSO Council. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

RE: [council] PEDNR Motion
by Alan Greenberg April 9, 2009

April 9, 2009

I am referring to the voting threshold needed to INITIATE a PDP. According to the Bylaws Annex A 3.c "A vote of more than 33% of the Council members present in favor of initiating the PDP will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a Supermajority Vote of the Council members present in favor of initiating the PDP will be required to initiate the PDP." Although the start of it was before my time, I was told that PDP06 (gTLD Contractual Conditions) was deemed by ICANN Legal Counsel to be outside of GNSO Scope and required the higher threshold. In this present case, the Issues Report says and I have had it confirmed that the issue is within scope of the GNSO. Alan At 02/04/2009 05:16 PM, Gomes, Chuck wrote: >Alan, > >Please see my comments inserted below. > >Chuck > > > -----Original Message----- > > From: owner-council(a)gnso.icann.org > > [mailto:owner-council@gnso.icann.org] On Behalf Of Alan Greenberg > > Sent: Thursday, April 02, 2009 3:40 PM > > To: Tim Ruiz; GNSO Council > > Subject: RE: [council] PEDNR Motion > > > > > > Tim, I will let Marika definitively address that. > > But here is my understanding. > > > > There are two types of "out-of-scope": > > > > - Those that are deemed by legal council to be out of the > > GNSO scope, and those require a higher threshold to initiate a PDP. > >Chuck: I do not know to what you are referring >regarding the latter, 'those require a higher >threshold to initiate a PDP'. Please explain. > > > > > - Those that are out-of-scope of the picket fence. If deemed > > to be within Council scope as above, they do not require the > > higher threshold, but of course cannot be used to set a > > consensus policy. > >Chuck: Again, where does the 'higher threshold' >concept come from. In the case of possible >consensus policies, if the Council recommends a >consensus policy with a supermajority vote, then >the threshold for the Board rejecting it is >higher than it is if the Council recommends it >with a simple majority vote. Is that what you are referring to? > > > > > I was told that the entire PEDNR issue is within GNSO scope, > > and it was worded as such based on that advice. But clearly > > only parts are within the picket fence of the RAA. > > > > All of this is not what I understood going into this process, > > but *IF* I got it right, that is the current interpretation > > according to staff. > > > > Alan > > > > At 02/04/2009 02:43 PM, Tim Ruiz wrote: > > > > >If that's the type of thing we want this group to look at then it > > >requires a different threshold of approval, correct? It's not > > >appropriate to try and include out of scope things with in > > scope things > > >because the latter has a lower threshold of approval to get started. > > > > > >So perhaps that's the fundamental question. But I suggest > > this motion > > >stick with what's in scope. > > > > > >Tim > > > > > > -------- Original Message -------- > > >Subject: RE: [council] PEDNR Motion > > >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > >Date: Thu, April 02, 2009 1:14 pm > > >To: GNSO Council <council(a)gnso.icann.org> > > > > > > > > >Tim, We are talking to different ends. I am talking about changes to > > >how compliance is measured or enforced. > > > > > >I will give a specific and current example. The February 2009 > > >Contractual Compliance Semi-Annual Report. One of the measures was > > >whether Registrars were honoring the Deletion and Renewal Consensus > > >Policy. This was carried out by reviewing Registrar web sites. > > > > > >ICANN Counsel has confirmed the a Registrar cannot avoid their > > >contractual obligations by simply sub-contracting the > > responsibilities > > >to others. This is explicitly reinforced in the recently > > approved RAA > > >Amendments. The Registrar is responsible if their > > subcontractor is not > > >adhering to the agreement. > > > > > >However, compliance staff have routinely said that they > > cannot consider > > >reseller issues, because ICANN does not have a contract with these > > >resellers. However, if one is to try to audit a registrar who has > > >sub-contracted obligations to a reseller, one must look at whether > > >their resellers are doing the job properly - there is no > > other way for > > >ICANN to independently conduct such an audit. Requiring that > > ICANN at > > >least sample resellers for those Registrars who use them should be > > >mandatory. > > > > > >To this end, I may be mistaken, but I don't believe that the > > RAA (old > > >or new) requires that Registrars disclose to ICANN who their > > resellers > > >are. Yet without this information, how can ICANN even > > pretend that they > > >are auditing their contracts. Adding such a requirement is > > exactly the > > >kind of issue that could only be addressed under the "advice > > for future > > >RAA amendments" type of PDP output. > > > > > >Alan > > > > > >At 02/04/2009 01:44 PM, Tim Ruiz wrote: > > > >Alan, > > > > > > > >My amendment uses the verbiage right out of the issues > > report. But to > > > >answer you question directly, I don't see any reason to include it. > > > > > > > >As Staff suggests in the issues report, the TF or WG > > should consider > > > >information from compliance Staff about how related > > current policy is > > > >enforced (related RAA provisions and related consensus policies). > > > >This information could be used by the group to craft > > consensus policy > > > >or consensus policy changes that complaince Staff could > > actually enforce. > > > >That's an expected consideration in any policy > > developement work and > > > >doesn't really need to be spelled out. > > > > > > > >Tim > > > > > > > > -------- Original Message -------- > > > >Subject: RE: [council] PEDNR Motion > > > >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > > >Date: Thu, April 02, 2009 12:06 pm > > > >To: "GNSO Council" <council(a)gnso.icann.org> > > > > > > > > > > > >Tim, we may agree to differ on this. > > > > > > > >In your proposed replacement motion, you also dropped and > > reference > > > >to the PDP process making recommendations to ICANN > > compliance staff. > > > >Do you have a reason for excluding this as well? > > > > > > > >Alan > > > > > > > >At 02/04/2009 12:03 PM, Tim Ruiz wrote: > > > > > > > > >Alan, > > > > > > > > > >That makes no sense whatsoever. What RAA changes could they > > > > >recommend that would be out of scope that would solve an > > in scope > > > > >issue they are considering? And why would they do that > > if the issue > > > > >is in scope? Why not just put it in terms of a consensus policy? > > > > >And how could a change to the RAA be less invasive than > > a consensus > > > > >policy, for all practical purposes they have the same effect? > > > > > > > > > >What this runs the risk of is the TF or WG skewing off. Any > > > > >situation where an out of scope change to the RAA would > > resolve an > > > > >in scope issue would be so extremely rare (and I assert > > impossible) > > > > >that it is not worth running this risk. > > > > > > > > > >Tim > > > > > > > > > > -------- Original Message -------- > > > > >Subject: RE: [council] PEDNR Motion > > > > >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > > > >Date: Thu, April 02, 2009 10:41 am > > > > >To: "GNSO Council" <council(a)gnso.icann.org> > > > > > > > > > > > > > > >Tim, two issues: > > > > > > > > > >First, just because we say that the group can make > > RECOMMENDATION > > > > >on ways the PEDNR issues could best e addressed through a future > > > > >RAA (non-picket fence) change does NOT give them the latitude to > > > > >address non-PEDNR issues. Although it is certainly > > jumping the gun > > > > >to consider PDP outcomes, one could imagine that a > > possible outcome > > > > >is a recommendation that a PEDNR issue would best be > > addressed by > > > > >some specific contractual term of the RAA. Not within the picket > > > > >fence, not binding, but a bit of advice that could then not be > > > > >lost, but used as per the (hopefully existent) process of RAA > > > > >amendment. > > > > > > > > > >I am not really expecting such "RAA-suggestion" > > > > >outcomes. But if it becomes obvious to the WG that this is the > > > > >least invasive away of addressing a problem, they should > > be allowed > > > > >to suggest it without them being accused of broadening > > their scope. > > > > >That is all it was meant to do. > > > > > > > > > >I understand that there are some people who want to use a "thin > > > > >edge of the wedge" to address every RAA issue under the > > sun, but I > > > > >think that Staff have crafted a pretty narrow definition here. > > > > > > > > > >Alan > > > > > > > > > >At 02/04/2009 11:24 AM, Tim Ruiz wrote: > > > > > > > > > > >It's unfortunate that Staff supported such a concept, and I > > > > > >personally believe it is seriously flawed. If we don't > > form WGs > > > > > >with specific focus we run the risk of them running on > > and on - > > > > > >getting sidetracked in multiple directions. > > > > > > > > > > > >Clearly, a PDP WG could come back and say: "We do not > > recommend > > > > > >any policy at this time, but suggest that the following be > > > > > >considered as a best practice..." That's much > > different than the > > > > > >WG spending time hashing out potential changes to the RAA. For > > > > > >one thing, if the issue is in scope they don't have > > to. A consensus policy IS a change to the RAA. > > > > > >If they conclude there is not a need for a policy, > > then why would > > > > > >they consider RAA changes? That is either a > > contradiction, or it > > > > > >gets them off looking at things they were not > > chartered to consider. > > > > > > > > > > > >For the PEDNR PDP being contemplated, Staff Council > > deemed it in scope. > > > > > >So if the PDP WG is formed it will look at possible > > new policy or > > > > > >policy changes (both of which are in effect changes to > > the RAA), > > > > > >and perhaps they will also consider best practices. > > But what is > > > > > >the point of looking at other RAA changes? The issue they are > > > > > >chartered for is deemed in scope so they don't need to > > - they can > > > > > >recommend a policy. If they are looking at RAA changes > > for something else, why? > > > > > > > > > > > > > > > > > >Tim > > > > > > > > > > > > -------- Original Message -------- > > > > > >Subject: RE: [council] PEDNR Motion > > > > > >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > > > > >Date: Thu, April 02, 2009 10:02 am > > > > > >To: "GNSO Council" <council(a)gnso.icann.org> > > > > > > > > > > > > > > > > > >I slept in a bit today, and apparently I missed the > > start of the party! > > > > > > > > > > > >Let me try to clarify things. First, there are two variants of > > > > > >PDPs, both of which can be "in scope for GNSO > > consideration". I > > > > > >must admit that I was not clear on some of this when the > > > > > >discussions started, but I think/hope that what I have below > > > > > >reflect the opinions of both Marika and ICANN Counsel. > > > > > > > > > > > >1. Those that formulate a consensus policy for adoption by the > > > > > >Board. Clearly the resultant policy must also be with > > the scope > > > > > >of the definition of consensus policy within the applicable > > > > > >contract (within the "picket fence"). > > > > > > > > > > > >2. Those that give advice to the Board. They may be completely > > > > > >off-topic from contract allowed consensus policies. > > The new gTLD > > > > > >policy is such an example. It is not binding on contracted > > > > > >parties. Such PDPs can even be deemed out of scope for > > the GNSO. > > > > > >The Contractual Terms PDP06 was an example - it > > required a higher > > > > > >threshold to start. > > > > > > > > > > > >During the discussions that led to where we are today (both in > > > > > >the DT and before), and as indicated in the Issues Report. The > > > > > >problems that we are discussing may be addressed through a > > > > > >variety of mechanisms. Council has been very leery of WGs that > > > > > >enlarge their charters while operating, so it was felt > > important > > > > > >to make it clear that all forms of output are allowed in this > > > > > >case. The Motion was an attempt at saying that there > > is no reason > > > > > >to limit a PDP to just one type of output if its deliberations > > > > > >lead it to belive that several are needed to address > > the problem > > > > > >properly. > > > > > > > > > > > >a) those which are within the picket fence in the RAA could > > > > > >result in a consensus policy recommendation to the Board. > > > > > >b) those that would require changes to the RAA but are > > outside of > > > > > >the picket fence and would have no more import than > > other input > > > > > >from the community into future revisions. But > > importantly, they > > > > > >would not be lost as they would be if they could not be one > > > > > >aspect of the output of the PDP. > > > > > >We have too much work to do to analyze problems and > > then simply > > > > > >discard the results. > > > > > >c) there could be recommendation for changes in > > compliance made > > > > > >to the Board for implementation by ICANN compliance staff. > > > > > >d) there could be recommendations for best practices for > > > > > >Registrars, which would be no more than just that - > > > > > >recommendations not binding on anyone unless > > Registrars choose to > > > > > >follow them. > > > > > > > > > > > >The entire intent to be able to address the problem that users > > > > > >see from a holistic point of view and look for the best way to > > > > > >address it, with the least amount of "thou shalt do". > > > > > > > > > > > >We always have the worry about a PDP being hijacked > > and discuss > > > > > >issues which were not included in the Issues Report or the > > > > > >Charter. In this case, Staff has written the > > recommendation which > > > > > >were quoted in the motion pretty restrictively. As the > > submitter > > > > > >of the request for Issues Report, I actually wish they > > had given > > > > > >more latitude. But that *IS* what they said, and the > > DT decided > > > > > >to not attempt to change them. > > > > > > > > > > > >Alan > > > > > > > > > > > > > > > > > >At 02/04/2009 09:40 AM, Tim Ruiz wrote: > > > > > > >Marika, > > > > > > > > > > > > > >You're not getting the point. A PDP charter should, in my > > > > > > >opinion, either directly or indirectly be directed > > NOT to get > > > > > > >sidetracked with consideration of *other* RAA changes. > > > > > > >Otherwise it implies considering issues that the PDP was not > > > > > > >formed to consider. If a PDP is engaged on an *in > > scope* issue > > > > > > >that could result in a consensus policy then it > > should focus on > > > > > > >that issue. We cannot have working groups going off in any > > > > > > >direction desired, and that's exactly what will > > happen if we don't keep them focused on the issue they were > > formed to consider. > > > > > > > > > > > > > >Tim > > > > > > > > > > > > > > -------- Original Message -------- > > > > > > >Subject: Re: [council] PEDNR Motion > > > > > > >From: Marika Konings <marika.konings(a)icann.org> > > > > > > >Date: Thu, April 02, 2009 8:15 am > > > > > > >To: Tim Ruiz <tim(a)godaddy.com> > > > > > > >Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council > > > > > > ><council(a)gnso.icann.org> > > > > > > > > > > > > > >Apologies Tim, but I did not mean to imply that staff is > > > > > > >encouraging PDPs to include possible RAA changes. I > > > understood the reason as to why > > > > > > >the drafting team decided to include > > > examples of other possible outcomes > > > > > > >of a PDP, such as a recommendation for RAA changes, > > to be that > > > > > > >the drafting team wanted to emphasize that consensus > > policy or > > > > > > >consensus policy changes are not the the only > > possible outcomes of a PDP. > > > > > > > > > > > > > >In reviewing some of the issues, a WG might decide > > that changes > > > > > > >to a consensus policy are not appropriate but > > > instead a recommendation for a > > > > > > >best practice or RAA change might be more suitable. You are > > > > > > >absolutely right that anything but consensus policy changes, > > > > > > >are recommendations and therefore not enforceable. > > This is how > > > > > > >I interpreted the reference to possible RAA changes. > > If this WG > > > > > > >were to make a recommendation for changes to the > > RAA, and the > > > > > > >GNSO would support this recommendation, it is my > > understanding > > > > > > >that it would be passed on to the appropriate parties, WG > > > > > > >and/or ICANN body to > > > consider this recommendation and follow > > > > > > >the applicable procedures which might result in > > changes to the > > > > > > >RAA, or not. > > > > > > > > > > > > > >Again, apologies for the confusion. > > > > > > > > > > > > > >Best regards, > > > > > > > > > > > > > >Marika > > > > > > > > > > > > > >On 4/2/09 2:42 PM, "Tim Ruiz" > > > > > > ><https://email.secureserver.net/tim@godaddy.com> wrote: > > > > > > > > > > > > > > Marika, > > > > > > > > > > > > > >Thanks for the explanation. But why is Staff > > encouraging PDPs > > > > > > >to include possible RAA changes? A consensus policy IS an > > > > > > >enforceable change to the RAA. The only other reason > > would be > > > > > > >to change something not within the scope of the RAA picket > > > > > > >fence. Such things should NOT be part of a PDP. > > > > > > > > > > > > > >A PDP should be specifically for *policy* > > development. If the > > > > > > >GNSO wants to consider things not within scope of the picket > > > > > > >fence it should not initiate a PDP. It can very well form a > > > > > > >group to consider such things if it chooses with the > > > > > > >understanding that the outcome will not be a mandate > > but only a > > > > > > >suggestion or possibly a recommended (but not > > enforceable) best > > > > > > >practice. Mixing these things together is NOT a > > productive way to approach our work. > > > > > > > > > > > > > >In fact, we are forming such a group to discuss > > further changes > > > > > > >to the RAA. That group will no doubt discuss things > > not within > > > > > > >the RAA's picket fence as well as some things that > > are. For me, > > > > > > >if this PDP is going to proceed with the > > understanding that it > > > > > > >will include dicussion/examination of changes to the > > RAA, then > > > > > > >I see no point in purusing any other discussion of the RAA. > > > > > > > > > > > > > >That all said, I would like to ask for the > > following, intended > > > > > > >friendly ammendment to the PEDNR motion: > > > > > > > > > > > > > >Replace the main paragraph of the RESOLVE portion with this: > > > > > > > > > > > > > >to initiate a Policy Development Process (PDP) to > > address the > > > > > > >issues identified in the Post-Expiration Domain Name > > Recovery > > > > > > >Issues Report. The charter for this PDP should > > instruct the Working Group: > > > > > > >(i) that it should consider recommendations for best > > practices > > > > > > >as well as or instead of recommendations for > > Consensus Policy; > > > > > > >(ii) that to inform its work it should pursue the > > > availability of further information > > > > > > > > > > > > > >from ICANN compliance staff to understand how current RAA > > > > > > >provisions and consensus policies regarding deletion, > > > > > > >auto-renewal, and recovery of domain names during > > the RGP are > > > > > > >enforced; and (iii) that it should specifically > > consider the following questions: > > > > > > > > > > > > > >Also, I would suggest that the last bullet/question > > be deleted > > > > > > >since the last paragraph really covers it. So to be > > clear, if > > > > > > >my proposed amendment is accepted as friendly the RESOLVE > > > > > > >portion of the motion would read: > > > > > > > > > > > > > >GNSO Council RESOLVES: > > > > > > > > > > > > > >to initiate a Policy Development Process (PDP) to > > address the > > > > > > >issues identified in the Post-Expiration Domain Name > > Recovery > > > > > > >Issues Report. The charter for this PDP should > > instruct the Working Group: > > > > > > >(i) that it should consider recommendations for best > > practices > > > > > > >as well as or instead of recommendations for > > Consensus Policy; > > > > > > >(ii) that to inform its work it should pursue the > > > availability of further information > > > > > > > > > > > > > >from ICANN compliance staff to understand how current RAA > > > > > > >provisions and consensus policies regarding deletion, > > > > > > >auto-renewal, and recovery of domain names during > > the RGP are > > > > > > >enforced; and (iii) that it should specifically > > consider the following questions: > > > > > > > > > > > > > >-- Whether adequate opportunity exists for registrants to > > > > > > >redeem their expired domain names; > > > > > > >-- Whether expiration-related provisions in typical > > > > > > >registration agreements are clear and conspicuous enough; > > > > > > >-- Whether adequate notice exists to alert registrants of > > > > > > >upcoming expirations; > > > > > > >-- Whether additional measures need to be implemented to > > > > > > >indicate that once a domain name enters the Auto-Renew Grace > > > > > > >Period, it has expired (e.g. hold status, a notice > > on the site > > > > > > >with a link to information on how to renew or other > > options to be determined). > > > > > > > > > > > > > >The GNSO Council further resolves that the issue of > > logistics > > > > > > >of possible registrar transfer during the RGP shall be > > > > > > >incorporated into the charter of the IRTP Part C charter. > > > > > > > > > > > > > > > > > > > > >Tim > > > > > > > > > > > > > > -------- Original Message -------- > > > > > > >Subject: Re: [council] PEDNR Motion > > > > > > >From: Marika Konings > > > > > > ><https://email.secureserver.net/marika.konings@icann.org> > > > > > > >Date: Thu, April 02, 2009 4:20 am > > > > > > >To: Alan Greenberg > > > > > > ><https://email.secureserver.net/alan. > gree> > nberg(a)mcgill.ca>, GNSO Council > > > > > > ><https://email.secureserver.net/council@gnso.icann.org> > > > > > > > > > > > > > >Tim, please note that the recommendation you quoted from the > > > > > > >Issues Report specifically relates to > > > > > > > > > ÃÆÃÆÃÃÆÃÆÆÃÃÃÂ¢ÃÆÃÆÃÃÃÆÃÃÃÃÆÃâÃâ¬ÃÆÃÆÃÃÃÆÃÃÃthe > > > desired outcomes utcomes stated by ALAC in > > > > > > >its > > > > requestÃÆÃÆÃâÃÆÃÆÃÃÃÂ¢ÃÆÃÆÃÃÃÆÃÃÃÃâÃâÃÃÆÃÆÃÃÃÆÃÃÃ, > > > some of wh some of which > > > go > > > > > beyond the issues recommended for a > > > > > > >PDP. As noted by Alan, the drafting team > > > and staff did discuss whether a > > > > > > >pre-PDP WG would be appropriate, but agreed that further > > > > > > >research and consultation could be done as part of a > > PDP as the > > > > > > >issues recommended for inclusion in a PDP have been narrowly > > > > > > >defined. As stated in the motion, the drafting team does > > > > > > >believe it is important to highlight in the charter that the > > > > > > >outcomes of a PDP are not limited to recommended changes to > > > > > > >consensus policy, but could also include recommendations > > > > > > >regarding e.g. best practices, compliance, possible > > RAA changes or further dialogue. > > > > > > > > > > > > > >On a different note, but related to the > > Post-Expiration Domain > > > > > > >Name Recovery Issues Report, I would like to draw your > > > > > > >attention to a deletion and renewal consensus policy > > audit in > > > > > > >relation to the Expired Domain Deletion Consensus > > Policy that > > > > > > >was > > > > > carried out by the > > > > > > ICANNÃÆÃÆÃÃÆÃÆÃÃÃÂ¢ÃÆÃÆÃÃÃÆÃâÃÆÃÃÃÃÆÃÆÃÃÃÆÃÃÃs > > >âÃâ¢s > > > > > > >compliance team recently (see further > > > details attached). Follow-up audit > > > > > > >activity is being carried out as a result of the > > non-compliance > > > > > > >identified in the audit. As a result of this follow-up, the > > > > > > >compliance team estimates that the number of non-compliant > > > > > > >registrars is about 30-40% less today then when the > > report was published. > > > > > > > > > > > > > >With best regards, > > > > > > > > > > > > > >Marika > > > > > > > > > > > > > >On 4/2/09 5:11 AM, "Alan Greenberg" > > > > > > > > ><https://email.secureserver.net/alan.greenberg@mcgill.ca> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >The drafting team did discuss this. The conclusion was (and > > > > > > >staff concurred if I remember correctly) that any further > > > > > > >consultation could reasonably be done as part of the PDP. We > > > > > > >also talked about a public forum in Sydney, the > > exact contents > > > > > > >of which would depend on how far along the WG > > (presuming we use a WG) had gotten. > > > > > > > > > > > > > >I guess the question came down to whether we felt that some > > > > > > >policy development and non-policy recommendations > > were required > > > > > > >regardless, and whether the outcomes of pre-PDP consultation > > > > > > >would change the details of the recommendations to > > be put in a > > > > > > >PDP charter. The answer to the first question was > > yes, we did > > > > > > >feel that PDP action was required, and we did not think that > > > > > > >the specific recommendations would change. How a WG > > addresses > > > > > > >the issues may well change, but since it did not appear that > > > > > > >the results of such consultation would alter the PDP > > charter, there did not seem to be any reason to delay. > > > > > > > > > > > > > >Although not discussed, I would envision a call for input on > > > > > > >some targeted questins as an early part of the process. > > > > > > > > > > > > > >Alan > > > > > > > > > > > > > >At 01/04/2009 06:09 PM, you wrote: > > > > > > > > > > > > > > >I was re-reading the issues report and was > > reminded of this > > > > > > > >Staff > > > > > > > >recommendation: > > > > > > > > > > > > > > > >"In relation to the desired outcomes stated by ALAC in its > > > > > > > >request, ICANN staff notes that while most, if not all, > > > > > > > >outcomes might be achieved by the recommendations > > identified > > > > > > > >by the ALAC, it would be helpful for all > > > > parties concerned to engage in a more > > > > > > > >fulsome dialogue on > > > > > > > >the extent and detailed nature of the concerns to > > determine > > > > > > > >whether these are shared desired outcomes and if so, how > > > > > > > >these > > > > could best be addressed in policy > > > > > > > >work going > > > > > > > >forward, including a more robust > > > > discussion of the merits and drawbacks > > > > > > > >of various solutions > > > > > > > >to address agreed concerns. The GNSO Council might > > consider > > > > > > > >such an activity, which could take the form of one or more > > > > public workshops at an upcoming ICANN > > > > > > > >meeting, for > > > > > > > >example, as a precursor for the launch of a PDP as > > it would > > > > > > > >help to define and focus the policy development process on > > > > > > > >one or more specific proposed changes. > > > > > > > >While this could > > > > > > > >also be explored by a working group > > > > following the launch of a PDP, staff > > > > > > > >recommends > > > > > > > >further fact finding first to figure out what > > policy options > > > > > > > >might exist, and then conduct a PDP to assess the > > impact of > > > > > > > >those policy options and confirm community support for a > > > > > > > >preferred policy choice." > > > > > > > > > > > > > > > >I don't recall that we discussed whether > > > > we should follow this advice or > > > > > > > >not. Alan, is there > > > > > > > >a reason why your motion initiates a PDP instead > > of the fact > > > > > > > >finding that the Staff suggests be done first? > > > > > > > > > > > > > > > > > > > > > > > >Tim > > > > > > > >

4 6

Notice of New Registry Service Proposal
by Patrick Jones April 9, 2009

April 9, 2009

Dear Council members, ICANN has commenced its 15-calendar day preliminary determination period on a request from RegistryPro to modify handling of names pending verification. Information on the proposal can be found at http://www.icann.org/en/registries/rsep/#2009001. Although public comments can be submitted at any time on a registry services proposal to registryservice at icann.org, this is not notification of a formal comment period. Information on the Registry Services Evaluation Process can be found at http://www.icann.org/registries/rsep/. Please let me know if you have additional questions. Regards, Patrick -- Patrick L. Jones Registry Liaison Manager & Support to ICANN Nominating Committee Internet Corporation for Assigned Names & Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 301 3861 Fax: +1 310 823 8649 patrick.jones(a)icann.org

1 1

Draft GNSO Council Agenda 16 April 2009 at 14:00 UTC
by Glen de Saint Géry April 9, 2009

April 9, 2009

Dear Councillors, Attached and in plain text below, please find the draft GNSO Council agenda for Thursday, 16 April 2009. The agenda is also posted on the Wiki at: https://st.icann.org/gnso-council/index.cgi?agenda_16_april_2009 The motions are posted on the Wiki at: https://st.icann.org/gnso-council/index.cgi?16_april_motions Please note the change of time to 14:00 UTC. Please let me know if you have any questions. Thank you. Kind regards, Glen .............................................................................. Proposed GNSO Council Agenda 16 April 2009 http://gnso.icann.org/meetings/agenda-16april09.shtml Item 0: Roll call of Council members (5 mins) Item 1: Update any statements of interest (5 mins) Item 2: Review/amend agenda (5 mins) Item 3: Approve GNSO Council minutes (5 mins) GNSO Council minutes 26 March 2009 http://gnso.icann.org/mailing-lists/archives/council/msg06583.html Item 4: Inter-Registrar Transfer Policy (IRTP) Part A Policy Development Process (PDP) (deferred from previous meeting) (20 mins) - 4.1 Staff Presentation of IRTP Part A PDPFinal Report http://gnso.icann.org/correspondence/irtp-part-a-report-presentation-16apr0… - 4.2 Vote See motion on the Wiki page: https://st.icann.org/gnso-council/index.cgi?16_april_motions Item 5: Motion on next round of IRTP issues to address (15 mins) See motion on the Wiki page: https://st.icann.org/gnso-council/index.cgi?16_april_motions Item 6: Registrar Accreditation Agreement (RAA) Motion Action Items (continued from previous meeting) (Council) (10 mins) Resolution approved on 4 March: http://gnso.icann.org/resolutions/ Resolved: The GNSO Council supports the RAA amendments as documented in http://gnso.icann.org/drafts/current-list-proposed-raa-amendments-16dec08.p… and recommends to the Board that they be adopted at its meeting of March 6, 2009; http://www.icann.org/en/minutes/resolutions-06mar09.htm#09 Within 30 days of Board approval of the set of amendments, representatives from the GNSO community and the ALAC shall be identified to participate in drafting a registrant rights charter, as contemplated by the amendments and the current GNSO Council discussions, with support from ICANN staff. A draft charter shall be completed no later than July 31 2009; and Within 30 days of Board approval of the set of amendments, the GNSO Council will form a Drafting Team to discuss further amendments to the RAA and to identify those on which further action may be desirable. The Drafting Team should endeavor to provide its advice to the Council and ICANN staff no later than July 31, 2009. Item 7: Post-Expiration Domain Name Recovery Policy Development Process (PDP) decision (Alan Greenberg/Drafting Team) (10 mins) Proposed Motion on Post-Expiration Domain Name Recovery Whereas on 05 December 2008, the GNSO received an Issues Report on Post-Expiration Domain Name Recovery (PEDNR); Whereas on 29 January 2009 the GNSO Council decided to form a Drafting Team (DT) to consider the form of policy development action in regard to PEDNR; Whereas a DT has formed and its members have discussed and reviewed the issues documented in the Issues Report; Whereas the DT has concluded that although some further information gathering may be needed, it should be done under the auspices of a PDP; Whereas staff has suggested and the DT concurs that the issue of registrar transfer during the RGP might be better handled during the IRTP Part C PDP. The GNSO Council RESOLVES to initiate a Policy Development Process (PDP) to address the issues identified in the Post-Expiration Domain Name Recovery Issues Report. The charter of the Task Force or Working Group charged with carrying out this PDP should include a mandate to consider both Consensus Policy recommendations as well as recommendations regarding best practices, ICANN compliance obligations and possible RAA changes, all associated with staff recommendations in the Issues Report section 4.2. Specifically, consideration of the following questions: . Whether adequate opportunity exists for registrants to redeem their expired domain names; . Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough; . Whether adequate notice exists to alert registrants of upcoming expirations; . Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined). . Whether to allow the transfer of a domain name during the RGP. The GNSO Council further resolves that the issue of logistics of possible registrar transfer during the RGP shall be incorporated into the charter of the IRTP Part C charter. Item 8: Whois service requirements motion (10 mins) See motion on the Wiki page: https://st.icann.org/gnso-council/index.cgi?16_april_motions Item 9: Motion on Travel Funding (10 mins) See motion on the Wiki page: https://st.icann.org/gnso-council/index.cgi?16_april_motions Item 10: New Bylaw discussion (10 mins) Item 11: Status Updates (15 mins) 11 . 1 Board Update http://www.icann.org/en/minutes/resolutions-06mar09.htm 11. 2 ccNSO Liaison update 11. 3 Geographical Region WG update 11. 4 Implementation Recommendation Team (IRT) status update http://www.icann.org/en/minutes/resolutions-06mar09.htm#07 11. 5 Joint GNSO/ccNSO group to discuss coordination of timing for IDN TLDs (Avri Doria /Chris Disspain) update 11. 6 Policy Items 11. 6. 1. Working Groups 11. 6. 1. 1. Fast Flux 11. 6. 1. 2. Registration Abuse Policies Working Group (RAPWG) 11. 6. 2. Drafting Teams 11. 6. 2.1. Travel Policy Drafting Team - Travel Database for Sydney http://gnso.icann.org/mailing-lists/archives/council/msg06424.html 11. 6. 2. 2. Response to IDN ccTLD Fast Track 11. 6. 3 GNSO Improvement Work Teams 11. 6. 3. 1 Policy Process Steering Committee (PPSC) Policy Development Process (PDP) work team (WT) 11. 6. 3. 2. PPSC Working Group work team WGWT 11. 6. 3. 3. Operations Steering Committee (OSC) Communications coordination work team 11. 6. 3. 4. OSC Constituency operations work team 11. 6. 3. 5. OSC GNSO Council operations work team 11. 7. Restructuring group http://gnso.icann.org/meetings/pending-action-list.pdf - deadlines to be met Item 12: AOB (07:00 Los Angeles, 10:00 Washington DC, 15:00 London, 1600 Brussels, 00:00 Melbourne next day) ---------------------------------------------------------------------------- Local time between March and October, Summer in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 14:00 ---------------------------------------------------------------------------- California, USA (PST) UTC-7+1DST 07:00 New York/Washington DC, USA (EST) UTC-4+1DST 10:00 Buenos Aires, Argentina UTC-3+0DST 11:00 Rio de Janeiro, Brazil UTC-3+0DST 11:00 London, United Kingdom (BST) UTC+1DST 15:00 Brussels, Belgium (CET) UTC+1+1DST 16:00 Paris, France (CET) UTC+1+1DST 16:00 Barcelona, Spain (CET) UTC+1+1DST 16:00 Karachi, Pakistan UTC+5+0DST 20:00 Hong Kong, China UTC+8+0DST 22:00 Singapore, Singapore UTC+8+0DST 22:00 Melbourne, Australia (EDT) UTC+10+0DST 00:00 (Friday) ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of October 2009, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

RE: [council] Motion on Travel Funding
by Tim Ruiz April 9, 2009

April 9, 2009

Actually, I may have only sent them to the Travel DT, just options to help us develop a proposal. But I believe the scenario in your motion was the one supported by the DT members. Tim -------- Original Message -------- Subject: Re: [council] Motion on Travel Funding From: Stéphane Van Gelder <stephane.vangelder(a)indom.com> Date: Thu, April 09, 2009 7:52 am To: "Rosette, Kristina" <krosette(a)cov.com>, GNSO Council <council(a)gnso.icann.org> Hi Kristina, No. The aim of the motion is to allocate the left-over DNSO funds for Sydney in an equitable manner amongst all Constituencies. The motion doesn’t go any further than that. Two general scenarios have been put forward by Tim Ruiz, who is also on the DT. I did not include them in the motion because the first matter of urgency is for the Council to actually decide that the funds will be used, or not, for the provision of extra travel funding. Each of Tim’s scenarios is an attempt to allocate the funds according to the number of Constituencies, while taking some measure of account of the funding already used this fiscal year by each Constituency. I believe Tim has previously sent these scenarios to the Council list, so we can discuss them during our discussion on this motion if Council members wish to. Thanks, Stéphane Le 09/04/09 04:32, « Rosette, Kristina » <https://email.secureserver.net/krosette@cov.com> a écrit : Thanks, Stéphane. Is the practical effect of this motion to fund slots for 7 persons per constituency for the current fiscal year? From: https://email.secureserver.net/owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Stéphane Van Gelder Sent: Wednesday, April 08, 2009 4:50 PM To: 'GNSO Council' Subject: [council] Motion on Travel Funding Hello all, As you know, the travel drafting team has been working on proposals to best manage TF allocation. As you also know, there has been a proposal to use left-over DNSO funds to help “top up” the amount of funding available for the final meeting of the current fiscal year, which is Sydney (any work the DT is now working on would not have any effect until the next fiscal year). In light of this, the DT has opted to put forward a motion for our next council meeting. This is the motion proposal which I have drafted on behalf of the DT and wanted to get in before the deadline (which is today, right?). Comments and thoughts welcome. Thanks. Stéphane Whereas: At its meeting of September 25, 2008 the GNSO Council created the Travel Drafting Team (TDT) to work on proposals to optimize the allocation and the management of Travel Funding for the GNSO Constituencies. At a meeting held during the Mexico ICANN meeting in March 2009 between the TDT and members of ICANN staff, the TDT requested that all GNSO Constituencies receive Funding Slots for each of their elected Councillors at each one of the three yearly international ICANN meetings, with the understanding that it would then be up to each Constituency to allocate these slots according to their own internal processes. That request stemmed in part from the recognition of the significant, and ever increasing work loads, that GNSO Councillors face. Work which they carry out as unpaid volunteers. Since that meeting it has been identified that an amount of funds left over from the DNSO are available for use should the Council wish to provide additional Travel Funding to those GNSO Constituencies that no longer have enough credits left for their three slots for the final meeting of the fiscal year 2008, in Sydney. The funds identified are in the amount of 19,963.79 USD. Resolved: That the DNSO funds be distributed evenly across all six GNSO Constituencies in time for the Sydney meeting in June, with the express purpose of providing additional Travel Funding for those persons nominated by each Constituency as recipients to be of said Travel Support.

2 1

Motion on Travel Funding
by Stéphane Van Gelder April 9, 2009

April 9, 2009

Hello all, As you know, the travel drafting team has been working on proposals to best manage TF allocation. As you also know, there has been a proposal to use left-over DNSO funds to help ³top up² the amount of funding available for the final meeting of the current fiscal year, which is Sydney (any work the DT is now working on would not have any effect until the next fiscal year). In light of this, the DT has opted to put forward a motion for our next council meeting. This is the motion proposal which I have drafted on behalf of the DT and wanted to get in before the deadline (which is today, right?). Comments and thoughts welcome. Thanks. Stéphane Whereas: At its meeting of September 25, 2008 the GNSO Council created the Travel Drafting Team (TDT) to work on proposals to optimize the allocation and the management of Travel Funding for the GNSO Constituencies. At a meeting held during the Mexico ICANN meeting in March 2009 between the TDT and members of ICANN staff, the TDT requested that all GNSO Constituencies receive Funding Slots for each of their elected Councillors at each one of the three yearly international ICANN meetings, with the understanding that it would then be up to each Constituency to allocate these slots according to their own internal processes. That request stemmed in part from the recognition of the significant, and ever increasing work loads, that GNSO Councillors face. Work which they carry out as unpaid volunteers. Since that meeting it has been identified that an amount of funds left over from the DNSO are available for use should the Council wish to provide additional Travel Funding to those GNSO Constituencies that no longer have enough credits left for their three slots for the final meeting of the fiscal year 2008, in Sydney. The funds identified are in the amount of 19,963.79 USD. Resolved: That the DNSO funds be distributed evenly across all six GNSO Constituencies in time for the Sydney meeting in June, with the express purpose of providing additional Travel Funding for those persons nominated by each Constituency as recipients to be of said Travel Support.

3 4

Follow-Up to the e-Crime and Abuse of the DNS Forum in Mexico City
by Margie Milam April 9, 2009

April 9, 2009

Dear All, We would like to thank the ICANN Community for its participation in the e-Crime and Abuse of the DNS Forum that took place during the 34th ICANN Meeting in Mexico City. We greatly appreciate the information that was shared during the Break-Out Sessions and the Q&A. The Forum was very well-received and was effective in communicating the complex issues faced by those in the Community tackling this multifaceted subject. To continue the dialogue in the Community, ICANN has posted additional information on the e-Crime Forum and recommendations from the Break-out Sessions held in conjunction with the e-Crime Forum on the following topics: ccTLDs and Law Enforcement Protecting Consumers in New and Existing TLDs The Role of ICANN in Responding to e-Crime E-Crime in Latin America We invite you to review at your convenience the summary of the e-Crime and Abuse of the DNS Forum at the link below. http://mex.icann.org/node/3638 We also would like to receive feedback and suggestions from the Community on whether follow-up sessions would be appropriate at the 35th ICANN Meeting to be held in Sydney June 21-26. We have already received suggestions for additional in-depth sessions on ccTLDs and Law Enforcement, and on protecting consumers from e-Crime and DNS abuse. If you believe that it is important to continue to address this topic in Sydney, please reply by Friday, April 17th with your thoughts on the format, topics, and other ideas for additional sessions on this topic. Thank you for your assistance in this regard. Best regards, Margie Milam Senior Policy Counselor ICANN

1 0

RE: [council] Action Item related to Whois Service Requirements
by Tim Ruiz April 8, 2009

April 8, 2009

My concern is prioritizing at the Council level. Managing the policy process should include some consideration of time and resource management. That will naturally allow Staff to prioritize, or as Philip suggested, allow us to direct Staff appropriately on priority of the work we've asked for. Tim -------- Original Message -------- Subject: Re: [council] Action Item related to Whois Service Requirements From: Stéphane Van Gelder <stephane.vangelder(a)indom.com> Date: Wed, April 08, 2009 3:52 am To: Philip Sheppard <philip.sheppard(a)aim.be>, "'GNSO Council'" <council(a)gnso.icann.org> I'm in a kind of half-way house about all this. On the one hand, I fully support Tim's comments that prioritising our work may lead to us actually getting things done. On the other, I do feel that it's our responsibility as GNSO Council to try and tackle all the important issues that lie before us, not just some of them. There's been a great deal of talk about volunteer burn-out since Mexico, and the fact that we find ourselves at the limit of what we can handle should be of great worry to the ICANN community as a whole. That's certainly an issue there that needs to be addressed. However, I do think Avri's motion on WHOIS is worthwhile having, just as I consider new gTLD work and GNSO improvement work crucial. Having staff alert us when they can no longer cope may be one way of dealing with the sheer volume of issues to be tackled by the GNSO Council. It implies that we rely on staff more and more to simplify our lives for us, which is no bad thing... Unless staff finds itself unable to cope with that (but they haven't sent us that signal so far I don't think). But I agree that the order in which we should do things is for us to initiate work on an issue, and then for staff to give us the timeframe in which they can reasonably be expected to handle that issue and the work we put their way on that issue. Checking with staff before we embark on something seems like taking something away from our role as the people responsible for setting things in motion as far as the issues the GNSO handles is concerned. Stéphane Le 08/04/09 09:23, « Philip Sheppard » <philip.sheppard(a)aim.be> a écrit : > > Chuck wrote: > "Maybe we should start by asking Staff whether they have the bandwidth to take > this on at > this time and if not request > an estimate as to when they think they would be able to do so". > > --------------------- > Chuck, this seems a little backwards and implies every current issue occupying > staff time > has greater priority than future ideas such as this. > A better way to proceed is for Council to make as many requests of staff as we > deem > necessary. > Staff management then respond and indicate resource constraints. They list the > activities > they are doing and request Council to prioritise the list. > We prioritise. > Staff act. > > Philip >

2 1

RE: [council] Action Item related to Whois Service Requirements
by Tim Ruiz April 8, 2009

April 8, 2009

To work well, it would help if we have prioritized our work at the Council level to begin with. Tim -------- Original Message -------- Subject: RE: [council] Action Item related to Whois Service Requirements From: "Gomes, Chuck" <cgomes(a)verisign.com> Date: Wed, April 08, 2009 7:57 am To: "Philip Sheppard" <philip.sheppard(a)aim.be>, "GNSO Council" <council(a)gnso.icann.org> Philip, Your suggested approach would seem to accomplish what I intended. Chuck > -----Original Message----- > From: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] On Behalf Of Philip Sheppard > Sent: Wednesday, April 08, 2009 3:24 AM > To: 'GNSO Council' > Subject: RE: [council] Action Item related to Whois Service > Requirements > > > Chuck wrote: > "Maybe we should start by asking Staff whether they have the > bandwidth to take this on at this time and if not request an > estimate as to when they think they would be able to do so". > > --------------------- > Chuck, this seems a little backwards and implies every > current issue occupying staff time has greater priority than > future ideas such as this. > A better way to proceed is for Council to make as many > requests of staff as we deem necessary. > Staff management then respond and indicate resource > constraints. They list the activities they are doing and > request Council to prioritise the list. > We prioritise. > Staff act. > > Philip > >

1 0

RE: [council] Action Item related to Whois Service Requirements
by Tim Ruiz April 8, 2009

April 8, 2009

Mike/Chuck, The WHOIS issue may very well be a priority in light of new IDN TLDs. Didn't mean to imply that it wasn't. Just pointing out that we may want to have a discussion about priorities so we know how to approach our work and manage our time, and what we would like Staff to focus on. For example, and this is just an example, anything to do with the new gTLD process and GNSO improvements have priority, next we have to finish work we've started but we should be cautious about starting anything else unless there is a proven urgency within the community. Or something like that. Tim -------- Original Message -------- Subject: RE: [council] Action Item related to Whois Service Requirements From: "Mike Rodenbaugh" <icann(a)rodenbaugh.com> Date: Tue, April 07, 2009 7:37 pm To: "'GNSO Council'" <council(a)gnso.icann.org> Good point Tim. Let's abandon the contentious (some might say 'ridiculous') aspects of the so-called 'GNSO Improvements' that so many of us are wasting so much time to address. Then we and Staff would have a lot more time to focus on important policy development issues like WHOIS. Mike Rodenbaugh Rodenbaugh Law 548 Market Street San Francisco, CA 94104 +1.415.738.8087 www.rodenbaugh.com -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz Sent: Tuesday, April 07, 2009 4:30 PM To: GNSO Council Subject: RE: [council] Action Item related to Whois Service Requirements Where does this fall priority wise within the plethora of issues we and staff are already dealing with right now? Seems we should be making some either/or types of decisions at this point in time. Tim -------- Original Message -------- Subject: [council] Action Item related to Whois Service Requirements From: Avri Doria <avri(a)acm.org> Date: Tue, April 07, 2009 11:51 am To: GNSO Council <council(a)gnso.icann.org> Hi, An action item I took away from the last meeting was to frame a request to the staff to collect the various requirements for a new Whois service tool or set of tools. In thinking about it, I decide that perhaps this should be a a formal request and should be done in the form of a motion. I have included a first draft of such a motion below. Please send comments. I plan to add it to the agenda for our next meeting. thanks a. Whereas there have been discussions for several years on the adequacy of the current set of Whois tools to provide the necessary functions to support existing and proposed Whois service policy requirements, and, there have been questions as to the adequacy of these tools for use in an IDN environment, and, that there have been extensive discussions about the requirements of the Whois service with respect to Registry and registrar operations, and, new architectures and tools have been developed and suggested by the technical community, resolved, The GNSO Council requests that Policy Staff, with the assistance of technical staff as required, collect and organize a comprehensive set of requirements for the Whois service policy tools. These requirements should reflect not only the known deficiencies in the current service but should include any possible requirements that may be needed to support various policy initiatives such as tiered services and privacy protection. The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and should be ready for community discussion in time for the Sydney meeting.

4 4

RE: [council] Action Item related to Whois Service Requirements
by Tim Ruiz April 8, 2009

April 8, 2009

Where does this fall priority wise within the plethora of issues we and staff are already dealing with right now? Seems we should be making some either/or types of decisions at this point in time. Tim -------- Original Message -------- Subject: [council] Action Item related to Whois Service Requirements From: Avri Doria <avri(a)acm.org> Date: Tue, April 07, 2009 11:51 am To: GNSO Council <council(a)gnso.icann.org> Hi, An action item I took away from the last meeting was to frame a request to the staff to collect the various requirements for a new Whois service tool or set of tools. In thinking about it, I decide that perhaps this should be a a formal request and should be done in the form of a motion. I have included a first draft of such a motion below. Please send comments. I plan to add it to the agenda for our next meeting. thanks a. Whereas there have been discussions for several years on the adequacy of the current set of Whois tools to provide the necessary functions to support existing and proposed Whois service policy requirements, and, there have been questions as to the adequacy of these tools for use in an IDN environment, and, that there have been extensive discussions about the requirements of the Whois service with respect to Registry and registrar operations, and, new architectures and tools have been developed and suggested by the technical community, resolved, The GNSO Council requests that Policy Staff, with the assistance of technical staff as required, collect and organize a comprehensive set of requirements for the Whois service policy tools. These requirements should reflect not only the known deficiencies in the current service but should include any possible requirements that may be needed to support various policy initiatives such as tiered services and privacy protection. The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and should be ready for community discussion in time for the Sydney meeting.

2 1

Action Item related to Whois Service Requirements
by Avri Doria April 7, 2009

April 7, 2009

Hi, An action item I took away from the last meeting was to frame a request to the staff to collect the various requirements for a new Whois service tool or set of tools. In thinking about it, I decide that perhaps this should be a a formal request and should be done in the form of a motion. I have included a first draft of such a motion below. Please send comments. I plan to add it to the agenda for our next meeting. thanks a. Whereas there have been discussions for several years on the adequacy of the current set of Whois tools to provide the necessary functions to support existing and proposed Whois service policy requirements, and, there have been questions as to the adequacy of these tools for use in an IDN environment, and, that there have been extensive discussions about the requirements of the Whois service with respect to Registry and registrar operations, and, new architectures and tools have been developed and suggested by the technical community, resolved, The GNSO Council requests that Policy Staff, with the assistance of technical staff as required, collect and organize a comprehensive set of requirements for the Whois service policy tools. These requirements should reflect not only the known deficiencies in the current service but should include any possible requirements that may be needed to support various policy initiatives such as tiered services and privacy protection. The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and should be ready for community discussion in time for the Sydney meeting.

2 1

Re: Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure
by William Drake April 7, 2009

April 7, 2009

From: Robin Gross <robin(a)ipjustice.org> Date: April 7, 2009 8:55:46 AM PDT To: liaison6c <liaison6c(a)gnso.icann.org> Cc: liaison6c <liaison6c(a)gnso.icann.org>, Council GNSO <council(a)gnso.icann.org >, Denise Michel <denise.michel(a)icann.org> Subject: Re: Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure Dear Denise, We appreciate your attempt to elaborate on the position you've taken, but in doing so you reinforce the view that you are no longer operating as a facilitator of the GNSO reform process, but rather as a dedicated advocate of a particular position. I really don't understand why you are involved in this discussion at this level. It is not your job to make policy decisions for the Board and it is not our task to convince you personally of the desirability of a particular GNSO structure. It is rather an issue to be settled among the stakeholders themselves and by the Board. The Board has proposals before it. Let the Board decide whether it likes them or not. Despite the length of your response, its substance can be boiled down into two simple points: 1) The GNSO Improvements Report indicates that constituencies should remain an important part of the reformed GNSO; 2) The Board has not given you specific instructions to change the assignment of Council seats to constituencies. Both of those points are true, yet neither justifies the position you are taking. 1) Constituencies can be an important and even central part of the GNSO process without being guaranteed a specific number of Council seats. Please note that the NCSG charter we submitted actually makes it easier to form constituencies - precisely because it detaches them from Council seat assignments. So in that respect, our proposal is more in line with the GNSO Improvement Report's references to "expanding Constituency involvement" and to "evening the playing field" among constituencies. 2) The absence of specific instructions applies in both directions. We recognize that the Board has not told you to do what we are proposing. But we also know that the position we are advocating is not ruled out by the GNSO Improvements Report, either. This means is it is an open issue. We should debate it and discuss it among ourselves, on the merits. We have had many discussions with Board members and none of them have suggested that what we are proposing is inconsistent with the GNSO Improvements principles. It is interesting that your responses keep ignoring the many, obvious problems that are posed by hardwiring Council seats to Constituencies. These include: the difficulty of achieving balanced geographic representation; the problem that occurs when the number of constituencies exceeds the number of seats; the fact that forming new constituencies becomes a zero-sum game that obstructs consensus. That is not an exhaustive list. Also, you seem not to understand a critical part of the BGC's recommendations, which is that working groups - not the Council - will formulate policy. It is the development of consensus in WGs - not the representation of votes in a legislative process - that is the objective of the Board's reforms. We hope you will be able to recognize these problems, and allow the stakeholder groups and the board the opportunity to work through the issues in the "bottom up" process we read about in so many ICANN press releases.. Thank you. Sincerely, Robin Gross, NCUC Chair on behalf of NCUC Executive Committee and GNSO Council: Norbert Klein Carlos Affonso Pereira de Souza Mary Wong William Drake Carlos Afonso Horacio Cadiz Georg Greve Robert Guerra Dave Kissoondoyal *********************************************************** William J. Drake Senior Associate Centre for International Governance Graduate Institute of International and Development Studies Geneva, Switzerland william.drake(a)graduateinstitute.ch New book: Governing Global Electronic Networks, http://tinyurl.com/5mh9jj ***********************************************************

1 0

Draft GNSO Council minutes 26 March 2009
by Glen de Saint Géry April 7, 2009

April 7, 2009

Dear Council Members, Attached please find the draft GNSO Council minutes of the meeting held on 26 March 2009. Please let me know if you would like any changes made. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

GNSO participants to receive ICANN travel support for Sydney
by Glen de Saint Géry April 7, 2009

April 7, 2009

Dear Councillors, Please find the GNSO list of participants selected by each constituency to receive ICANN Travel support for the Sydney meetings. This list, plus the database information will be forwarded to the ICANN Travel Staff. CBUC Philip Sheppard - Airfare, hotel, per diem - full suppport Zahid Jamil - Airfare, hotel, per diem - full suppport Mike Rodenbaugh - Airfare, hotel, per diem - full support ISP Tony Holmes - Airfare, hotel, per diem - full suppport Tony Harris - Airfare, hotel, per diem - full suppport Greg Ruth - hotel and per diem NCUC Mary Wong - hotel and per diem Robin Gross - Airfare Registrar c Clarke Walton - Airfare, hotel, per diem - full support Stéphane van Gelder - Airfare, hotel, per diem - full support Registry c Cherie Stubbs - Airfare, hotel, per diem - full support Nominating Committee Appointees Avri Doria - GNSO Council chair - Airfare, hotel, per diem - full support Olga Cavalli - Airfare, hotel, per diem - full support Terry Davis - Airfare, hotel, per diem - full support The IPC has still to submit names. Please let me know as soon as possible if there are any changes that should be made. Thank you very much. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

2 1

Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure
by Denise Michel April 6, 2009

April 6, 2009

Many thanks to all of you who have already commented on the draft revisions to the ICANN Bylaws relating to GNSO restructuring that were circulated late last week to start community discussion (also attached). Your emails were particularly useful in getting everyone to focus quickly on several specific issues. In this message, we'll attempt to address a number of the specific comments made Friday and over the weekend to give you some background on our drafting thoughts to help further the dialogue. Article X: §3.1 Issue: This proposed Bylaws amendment assigns the responsibility for selecting Council representatives to the four Stakeholder Groups with the stipulation that each Board-recognized Constituency shall be allocated a minimum of one seat on the GNSO Council. This article seems to have garnered the most immediate attention and questions. Rather than prejudging this issue, Staff's view was that this revision was entirely consistent with the GNSO Improvements Report, the Board's resolution, and various Board discussions to-date. Existing constituency Council seats are currently hard-wired into the Bylaws and no Board member or Board committee has suggested to us that this be changed. As discussed in greater detail below, elements in the Board-approved GNSO Improvements Report and in Board resolutions suggest that the role of Constituencies within the GNSO continues to be significant and merits ongoing support in the Bylaws. 1. The GNSO Improvements Report produced by the Board Governance Committee (BGC) and endorsed by the Board last June emphasized the continued primacy of the Constituency structure as a fundamental building block of the GNSO. The Report did not attempt to change the existing Bylaws mechanisms by which the Board evaluates and approves GNSO Constituencies, but instead recommended that the process be more fluid, open, and accessible. In fact, the Report contains many references to expanding Constituency involvement in the GNSO by (a) encouraging new groups to form, (b) providing those structures with standard "tool kits" of administrative services, (c) evening "the playing field" among constituencies, (d) creating general best-practice guidelines to ensure consistent operational practices across different groups, and (e) assuring the community that transparency, openness and fairness remain fundamental ICANN principles. The Report specifically states that: "It should be noted that we view the new stakeholder structure primarily as a way to organize the Council. While it will also encourage the constituencies to maximize their common interests, it does not on its own change the constituency structure itself." (Board GNSO Improvements Report, page 42). The ICANN Board, in its 1 October 2008 resolutions, reinforced its support for the following principles pertaining to the formation of the new Stakeholder Groups. The Board specifically requested that, in establishing the newly formed structures, all constituency members and other relevant parties comply with the Board's principles including, "The inclusion of new actors/participants, where applicable, and the expansion of constituencies (emphasis added) within Stakeholder Groups, where applicable." The GNSO Improvements Report anticipated the creation of a lightly structured Stakeholder Group (SG) organizational layer to be inserted between Constituencies and the GNSO Council with a primary responsibility to select/allocate/apportion GNSO Council seats among its Constituency members. It did not anticipate the elimination of Constituencies in favor of Stakeholder Groups, although some in the community now suggest that Constituencies may no longer be necessary. Staff's position is not new and, at the Board's direction, Staff has made every effort to share its understanding with the community over the past six months through informal discussions with Constituency leaders and by providing sample organizational templates designed to: (a) help the community assess existing Constituency charters; (b) guide the development of potential new Constituency charters; and (c) assist community leaders as they fashioned new Stakeholder Group (SG) charters. 2. Second, among the stated goals of restructuring is to encourage the formation of new Constituencies to enhance the diversity of viewpoints in ICANN. As is true in the current Bylaws, Staff's proposed amendment in this section continues to place the responsibility with the Board to determine if the viewpoint represented by the Constituency applicant is significant enough to be entitled to recognition and, thereby, a minimum of one Council seat. Based upon a few of the Stakeholder Group voting systems that have been submitted thus far, a newly approved Constituency may not gain a Council seat, which raises concerns about depriving the GNSO Council of the new voices that the Board formally recognizes. It is conceivable that, without the GNSO seat requirement, an incumbent interest group could control a Stakeholder Group and potentially prevent these new viewpoints from fully participating in the GNSO. Without the promise of being able to participate meaningfully at the Council level, Staff is concerned that prospective new organizations may not pursue the arduous tasks of organizing, petitioning, drafting a charter, and defending their viability in being formally recognized as a Constituency within the GNSO. Without Board protection in this potentially volatile and delicate vetting process, Constituencies in formation may cease to make the effort. If that reality should be allowed to unfold, the GNSO will have failed to achieve a vital element of the Board's vision. It has been suggested that there should not be a hard-wiring of Constituencies to Council seats and seat allocation should be a Stakeholder Group responsibility. We agree that SGs should have that responsibility, although not without any constraints, and this is reflected in these proposed Bylaws to spur consideration and discussion. The current allocation of Council seats to Constituencies has been hard-wired since 2003. It does not seem inconsistent to accord a similar right to each prospective new Constituency that is Board-approved. (See Article XX below for discussion of what happens in the future should we reach a point where the number of Constituencies exceeds the number of Council seats.) 3. Third, as it relates to the non-contracted party house, the GNSO restructuring removed three seats (collectively) from the Commercial Constituencies and provided a new Non-Commercial Stakeholder Group with six seats. The rationale for this shift was that this was appropriate because, with the proper outreach and recruitment activities, additional non-commercial Constituencies would be formed that would hold seats to represent different viewpoints on the GNSO Council. "...a new non-commercial Stakeholders Group must go far beyond the membership of the current Non-Commercial Users Constituency (NCUC). We must consider educational, research, and philanthropic organizations, foundations, think tanks, members of academia, individual registrant groups and other non- commercial organizations, as well as individual registrants, as part of a non-commercial registrants Stakeholders Group." (Board GNSO Improvements Report, page 32) Guaranteeing a Council seat to new Constituencies in this SG, which will have half of the Council's non-contracted party seats, provides assurance that diverse viewpoints will be represented and heard on the Council. §3.3 Issue: Procedures and voting threshold for removal of an NCA for cause. The language concerning removal of a Nominating Committee Appointee (NCA) for cause was included for completeness, but Staff is recommending that it (along with all non-PDP thresholds) be relocated to the GNSO Council's Operating Rules. The provision and voting thresholds, as specified for each house, were taken from the Working Group on GNSO Council Restructure (WG-GCR) Report approved by the Board in its 1 October 2008 meeting (see below). It is, Resolved (2008.10.01.09), the Board adopts all voting thresholds proposed in the WG-GCR Report. The Board requests that the GNSO develop any additional voting thresholds or categories that may be needed as part of its proposed GNSO Improvements Implementation Plan to be submitted to the Board for approval. This issue could conceivably be revisited in the context of the Council Operating Rules effort since it is anticipated that those rules would need to be approved by the Board before becoming effective. §3.6: Issue: Board Seats #13 and #14 As explained in the footnote to this section, the language presented in yellow highlight was recommended in the WG-GCR Report; however, it has not been approved by the Board. Staff is hoping to collect some final additional community feedback on the matter again this month and expects final Board action on this matter at it's 23 April meeting. Once the Board has acted, this section will be amended to reflect the Board's decision as to the methodology and any other rules pertaining to these selections. I have asked Rob to make a final request to constituency leaders for feedback on the Board Seat issue and he will follow up on that mater this week. §3.8 Issue: Confusion as to whether the NCAs are appointed to each voting house by the Nominating Committee. Staff acknowledges that the original wording in (a) and (b) could be interpreted in a way that was not intended by the drafters. Staff recommends the following amendment to this section to avoid ambiguity as to how the NCAs are actually selected/appointed to each voting house: a. The Contracted Party House includes the Registry Stakeholder Group (three members), the Registrar Stakeholder Group (three members), and one Nominating Committee Appointee (NCA) for a total of seven voting members; and b. The Non-Contracted Party House includes the Commercial Stakeholder Group (six members), the Non-Commercial Stakeholder Group (six members), and one Nominating Committee Appointee (NCA) for a total of thirteen voting members. The assignment of each Nominating Committee Appointee to a voting house is determined by the GNSO Council Operating Rules and Procedures. Article XX §5.1 Issue: Provision that the Board resolves any condition in which the number of Constituencies exceeds the available Council seats in a Stakeholder Group. Staff refers to the explanation provided above in response to Article X, §3.1. Arguably, this language may not need to be expressed in the Bylaws; however, Staff believes that it is important to recognize formally that this potential condition (i.e. Constituencies exceeding the number of SG Council seats) could have the effect of causing prospective new Constituencies to wonder how they can become involved if there are no remaining positions available. While the circumstance appears to be remote in today's environment, there should be a provision to address it before it occurs. If the Board elects to change the Council organization or voting structure then the Bylaws would have to be modified in any case. One alternative might be to move the language from this section to Article XX-Transition. §5.5 Issue: Transition language to map the existing Constituency seats to the new Stakeholder Groups. Staff emphasizes that this section of the transition article is only intended to map the existing Constituency seats (SGs do not yet formally exist) to the new Stakeholder Groups. §5.11 Issue: Voting thresholds for Policy Development Process As explained in an email sent to the Council list on Friday, 27 March by Ken Bour, the voting thresholds originally prescribed by the Working Group on GNSO Council Restructuring (WG-GCR) contained both PDP and non-PDP elements. In this re-drafting exercise, Staff recommended that the thresholds be parsed out as follows: the non-PDP voting thresholds will be contained in Council OR&P while the PDP thresholds will be included in Article XX-Transition until such time as the Policy Process Steering Committee (PPSC) and Policy Development Process (PDP) Work Team (Jeff Neumann, Chair) have completed deliberations and are prepared to recommend a formal revision to Annex A of the Bylaws. Since the PDP thresholds are currently specified in Annex A, which is not being revised as part of the Council restructuring effort, Staff recommends that the new PDP thresholds should be included in Article XX vs. Council OR&P. Article XX is a "transition" document only and, once the PDP voting thresholds are successfully relocated from Annex A to the Council OR&P (Staff's recommendation), Article XX can be removed from the Bylaws in its entirety (assuming all other transition matters are completed). Below are the voting thresholds recast into the two groupings: Non-PDP: a) Elect Council Chair: requires 60% of both houses. b) Remove NCA for Cause: requires 75% of both houses (excluding the NCA subject to removal); subject to Board approval. c) All other GNSO Council Business (default): requires majority of both houses. PDP: a) Create an Issues Report: requires more than 25% vote of both houses or majority of one house. b) Initiate a PDP within Scope: requires more than 33% vote of both houses or more than 66% vote of one house. c) Initiate a PDP not within Scope: requires a vote of more than 75% of one house and a majority of the other house ("Super Majority"). d) Approve a PDP without a Super Majority: requires a majority of both houses and further requires that one representative of at least 3 of the 4 Stakeholder Groups supports. e) Approve a PDP with a Super Majority: requires greater than 75% majority in one house and majority in the other house. The PDP thresholds (above) were taken from the consensus recommendation of the WG-GCR and have been approved by the Board. Staff recommends that, while the thresholds themselves are not subject to Council or community rewrite, the PPSC and PDP Work Team do have the goal of reengineering the entire PDP. If, in the course of those deliberations, it appears that some or all of the above thresholds need to be modified or recast, the Board will need to take those recommendations under advisement. Staff also notes that the Operations Steering Committee (OSC) and the GNSO Council Operations Team are working on developing the methods, procedures, administration, and tools (to become part of the Council OR&P) that will need to be in place when the Council takes its first bicameral vote, which could be as early as its June meeting in Sydney. General Comments Finally, contrary to a recent comment, Staff would like to clarify that it has not prejudged or "made up its mind" on any of these issues. As the GNSO Improvements Report noted: "Many details, of course, remain to be worked out concerning the new stakeholder structure for the Council, including the role of constituencies and/or interest groups within them. As noted earlier, we welcome the GNSO working with Staff to develop the appropriate Implementation Plan." (Board GNSO Improvements Report at page 33). In preparing the draft Bylaws, Staff has tried to track the implementation of GNSO Improvements and Restructuring to specific directions from the Board. We hope that this exercise serves to facilitate discussions on these important topics in order to resolve them in a timely manner. We welcome further conversation about how these elements might be achieved with different language. All Policy Staff involved can be reached via policy-staff(a)icann.org and +1-310-823-9358. Regards, Denise Michel Vice President, Policy

5 5

RE: [council] Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure
by Alan Greenberg April 6, 2009

April 6, 2009

Although it is correct that policy will be formulated in working groups, it is also important to remember that it is Council that will be deciding what policies to look at and formulating the charters of the working groups. The inability to speak on Council may well mean that the issues that are important to you do not get raised to the level where there is a WG to participate in. Alan At 05/04/2009 11:49 AM, Tim Ruiz wrote: >Thank you Avri. That is my view, and the RrC view as well. > >In addition to Avri's well reasoned comments it is my impression that >under this new structure the Council will be serving more in a >management role, as had been envisioned from the beginning but not yet >executed on well. The Working Groups is where the real policy work will >take place, and where it will be important for *voices* to be heard. If >that is true, then new constituencies will have the same opportunity as >all existing ones in that regard. Otherwise, giving such weight to >having a Councilor, seems backsliding on an issue that the new structure >is meant to address. > >Tim > > -------- Original Message -------- >Subject: Re: [council] Draft Revisions to the ICANN Bylaws Relating to >GNSO Restructure >From: Avri Doria <avri(a)psg.com> >Date: Sat, April 04, 2009 10:47 pm >To: "council(a)gnso.icann.org" <council(a)gnso.icann.org>, >policy-staff(a)icann.org >Cc: "liaison6c(a)gnso.icann.org" <liaison6c(a)gnso.icann.org> > > >Denise, > >Thank you for the detailed note on the Staff's position on these issues. > >In this not I want tomake a few points on the issue concerning the >changes to X.3.1 > >1. From the full report of the board (which is curiously difficult to >find on line: for those who need to get new copy it can be found at: >http://www.icann.org/topics/gnso-improvements/gnso-improvements-report-03fe… > >) >The Board requests the Council, with >support from Staff, to prepare suggested changes to the Bylaws, >within six months, regarding the Councilâs structure on the >basis of four broad stakeholder groups and voting practices >consistent with the principles outlined above. > >Thus unless the council agrees to the proposed amendments, they will not >constitute changes prepared by the council with the support of the >staff. In the case of the one council seat per constituency, I believe >the staff is advocating an position that can neither be warranted by the >Board recommendations nor by council decisions at this point. While the >recommendations made by the staff are appreciated as a starting point, >it is the GNSO council that must make the decisions. In reading your >discussion, I had the feeling you were presenting us with what you felt >was the only possible interpretation. I wish to take issue with this >assumption. > >2. I certainly see no language in the Board/BCG recommendations >requiring that each new constituency get a seat on the council. In fact >all of the discussions on seating in the council is at the SG level. >And my reading of the recommendations, as well as the length discussions >the council had with the BCG indicate the intention to de-link the seats >in the council from the constituency structure. Perhaps we will need to >get a ruling from the Board on this as it is difficult to proceed with >such diametrically opposed understandings on the board's decision. My >reading says that there is no direct linkage between the existence of a >constituency and a seat on the Council, though of course the SG has to >show that is is giving fair representation to all in the SG group - >whatever constituency they may be a member of or however many >constituencies they may be a member of. > >3. There was certainly no language indicating that once we got to more >then 6 constituencies in a non-contracted house or more then 3 >constituencies in the contracted house that we would need to restructure >yet again. I hope that we are successful in bringing new >constituencies into the process, and I think that a well defined WG >process will aid in doing so. But if the by-law change you and your >staff advocate were to be advanced, I believe that pain of an additional >restructuring as well as the waste of time and effort it would >constitute would work as a disincentive to the acceptance on new >constituencies. It would be as hard to add the 4th constituency to one >of the contracted house as it was to add new constituencies before the >reorg we are suffering through at the moment. I believe that creating >disincentives for the creation on new constituency was definitely not >something the Board was intending in its decision. > >4. While it is true that the reason for constituting new constituencies >is to allow greater voice, given the function of the future council as a >management group, and given that voice is dependent on WG participation >and not council membership, the subject of voice and a council seat are >orthogonal to each other. Thus I do not believe that a requirement for >one council seat for each new constituency can be backed up by an >interpretation of the requirements for change made by the Board. > >5. Finally it is up to the stakeholders charters, as approved by the >board to determine the process by which seats are allocated - this is >explicit in the BCG recommendation. Each of the SG has been given the >opportunity to design a fair and comprehensive system for doing so. The >Board will review each of these SGs in order to determine whether they >do or not. It seems to me that the right of self determination by the >SGs with the advice and consent of the Board must not be abrogated by >Policy Staff fiat. > >thanks > >a. > > > >On Tue, 2009-03-31 at 11:31 -0700, Denise Michel wrote: > > Many thanks to all of you who have already commented on the draft > > revisions to the ICANN Bylaws relating to GNSO restructuring that were > > circulated late last week to start community discussion (also > > attached). Your emails were particularly useful in getting everyone > > to focus quickly on several specific issues. In this message, weâll > > attempt to address a number of the specific comments made Friday and > > over the weekend to give you some background on our drafting thoughts > > to help further the dialogue. > > > > Article X: > > > > Â§3.1 Issue: This proposed Bylaws amendment assigns the > > responsibility for selecting Council representatives to the four > > Stakeholder Groups with the stipulation that each Board-recognized > > Constituency shall be allocated a minimum of one seat on the GNSO > > Council. > > > > This article seems to have garnered the most immediate attention and > > questions. Rather than prejudging this issue, Staffâs view was that > > this revision was entirely consistent with the GNSO Improvements > > Report, the Boardâs resolution, and various Board discussions > > to-date. Existing constituency Council seats are currently hard-wired > > into the Bylaws and no Board member or Board committee has suggested > > to us that this be changed. As discussed in greater detail below, > > elements in the Board-approved GNSO Improvements Report and in Board > > resolutions suggest that the role of Constituencies within the GNSO > > continues to be significant and merits ongoing support in the Bylaws. > > > > 1. The GNSO Improvements Report produced by the Board Governance > > Committee (BGC) and endorsed by the Board last June emphasized the > > continued primacy of the Constituency structure as a fundamental > > building block of the GNSO. The Report did not attempt to change the > > existing Bylaws mechanisms by which the Board evaluates and approves > > GNSO Constituencies, but instead recommended that the process be more > > fluid, open, and accessible. > > > > In fact, the Report contains many references to expanding Constituency > > involvement in the GNSO by (a) encouraging new groups to form, (b) > > providing those structures with standard âtool kitsâ of administrative > > services, (c) evening âthe playing fieldâ among constituencies, (d) > > creating general best-practice guidelines to ensure consistent > > operational practices across different groups, and (e) assuring the > > community that transparency, openness and fairness remain fundamental > > ICANN principles. The Report specifically states that: > > âIt should be noted that we view the new stakeholder structure > > primarily as a way to organize the Council. While it will also > > encourage the constituencies to maximize their common interests, it > > does not on its own change the constituency structure itself.â (Board > > GNSO Improvements Report, page 42). > > > > The ICANN Board, in its 1 October 2008 resolutions, reinforced its > > support for the following principles pertaining to the formation of > > the new Stakeholder Groups. The Board specifically requested that, in > > establishing the newly formed structures, all constituency members and > > other relevant parties comply with the Boardâs principles including, > > âThe inclusion of new actors/participants, where applicable, and the > > expansion of constituencies (emphasis added) within Stakeholder > > Groups, where applicable.â > > > > The GNSO Improvements Report anticipated the creation of a lightly > > structured Stakeholder Group (SG) organizational layer to be inserted > > between Constituencies and the GNSO Council with a primary > > responsibility to select/allocate/apportion GNSO Council seats among > > its Constituency members. It did not anticipate the elimination of > > Constituencies in favor of Stakeholder Groups, although some in the > > community now suggest that Constituencies may no longer be necessary. > > > > > > Staffâs position is not new and, at the Boardâs direction, Staff has > > made every effort to share its understanding with the community over > > the past six months through informal discussions with Constituency > > leaders and by providing sample organizational templates designed to: > > (a) help the community assess existing Constituency charters; (b) > > guide the development of potential new Constituency charters; and (c) > > assist community leaders as they fashioned new Stakeholder Group (SG) > > charters. > > > > 2. Second, among the stated goals of restructuring is to encourage > > the formation of new Constituencies to enhance the diversity of > > viewpoints in ICANN. As is true in the current Bylaws, Staffâs > > proposed amendment in this section continues to place the > > responsibility with the Board to determine if the viewpoint > > represented by the Constituency applicant is significant enough to be > > entitled to recognition and, thereby, a minimum of one Council seat. > > > > Based upon a few of the Stakeholder Group voting systems that have > > been submitted thus far, a newly approved Constituency may not gain a > > Council seat, which raises concerns about depriving the GNSO Council > > of the new voices that the Board formally recognizes. It is > > conceivable that, without the GNSO seat requirement, an incumbent > > interest group could control a Stakeholder Group and potentially > > prevent these new viewpoints from fully participating in the GNSO. > > Without the promise of being able to participate meaningfully at the > > Council level, Staff is concerned that prospective new organizations > > may not pursue the arduous tasks of organizing, petitioning, drafting > > a charter, and defending their viability in being formally recognized > > as a Constituency within the GNSO. Without Board protection in this > > potentially volatile and delicate vetting process, Constituencies in > > formation may cease to make the effort. If that reality should be > > allowed to unfold, the GNSO will have failed to achieve a vital > > element of the Boardâs vision. > > > > It has been suggested that there should not be a hard-wiring of > > Constituencies to Council seats and seat allocation should be a > > Stakeholder Group responsibility. We agree that SGs should have that > > responsibility, although not without any constraints, and this is > > reflected in these proposed Bylaws to spur consideration and > > discussion. The current allocation of Council seats to Constituencies > > has been hard-wired since 2003. It does not seem inconsistent to > > accord a similar right to each prospective new Constituency that is > > Board-approved. (See Article XX below for discussion of what happens > > in the future should we reach a point where the number of > > Constituencies exceeds the number of Council seats.) > > > > 3. Third, as it relates to the non-contracted party house, the GNSO > > restructuring removed three seats (collectively) from the Commercial > > Constituencies and provided a new Non-Commercial Stakeholder Group > > with six seats. The rationale for this shift was that this was > > appropriate because, with the proper outreach and recruitment > > activities, additional non-commercial Constituencies would be formed > > that would hold seats to represent different viewpoints on the GNSO > > Council. > > âa new non-commercial Stakeholders Group must go far beyond the > > membership of the current Non-Commercial Users Constituency (NCUC). > > We must consider educational, research, and philanthropic > > organizations, foundations, think tanks, members of academia, > > individual registrant groups and other non- commercial organizations, > > as well as individual registrants, as part of a non-commercial > > registrants Stakeholders Group.â (Board GNSO Improvements Report, page > > 32) > > > > Guaranteeing a Council seat to new Constituencies in this SG, which > > will have half of the Councilâs non-contracted party seats, provides > > assurance that diverse viewpoints will be represented and heard on the > > Council. > > > > > > Â§3.3 Issue: Procedures and voting threshold for removal of an NCA > > for cause. > > > > The language concerning removal of a Nominating Committee Appointee > > (NCA) for cause was included for completeness, but Staff is > > recommending that it (along with all non-PDP thresholds) be relocated > > to the GNSO Councilâs Operating Rules. The provision and voting > > thresholds, as specified for each house, were taken from the Working > > Group on GNSO Council Restructure (WG-GCR) Report approved by the > > Board in its 1 October 2008 meeting (see below). > > > > It is, Resolved (2008.10.01.09), the Board adopts all voting > > thresholds proposed in the WG-GCR Report. The Board requests that the > > GNSO develop any additional voting thresholds or categories that may > > be needed as part of its proposed GNSO Improvements Implementation > > Plan to be submitted to the Board for approval. > > > > This issue could conceivably be revisited in the context of the > > Council Operating Rules effort since it is anticipated that those > > rules would need to be approved by the Board before becoming > > effective. > > > > > > Â§3.6: Issue: Board Seats #13 and #14 > > > > As explained in the footnote to this section, the language presented > > in yellow highlight was recommended in the WG-GCR Report; however, it > > has not been approved by the Board. Staff is hoping to collect some > > final additional community feedback on the matter again this month and > > expects final Board action on this matter at itâs 23 April meeting. > > Once the Board has acted, this section will be amended to reflect the > > Boardâs decision as to the methodology and any other rules pertaining > > to these selections. I have asked Rob to make a final request to > > constituency leaders for feedback on the Board Seat issue and he will > > follow up on that mater this week. > > > > > > Â§3.8 Issue: Confusion as to whether the NCAs are appointed to > > each voting house by the Nominating Committee. > > > > Staff acknowledges that the original wording in (a) and (b) could be > > interpreted in a way that was not intended by the drafters. Staff > > recommends the following amendment to this section to avoid ambiguity > > as to how the NCAs are actually selected/appointed to each voting > > house: > > > > a. The Contracted Party House includes the Registry Stakeholder Group > > (three members), the Registrar Stakeholder Group (three members), and > > one Nominating Committee Appointee (NCA) for a total of seven voting > > members; and > > b. The Non-Contracted Party House includes the Commercial Stakeholder > > Group (six members), the Non-Commercial Stakeholder Group (six > > members), and one Nominating Committee Appointee (NCA) for a total of > > thirteen voting members. > > The assignment of each Nominating Committee Appointee to a voting > > house is determined by the GNSO Council Operating Rules and > > Procedures. > > > > > > Article XX > > > > Â§5.1 Issue: Provision that the Board resolves any condition in > > which the number of Constituencies exceeds the available Council seats > > in a Stakeholder Group. > > > > Staff refers to the explanation provided above in response to Article > > X, Â§3.1. > > > > Arguably, this language may not need to be expressed in the Bylaws; > > however, Staff believes that it is important to recognize formally > > that this potential condition (i.e. Constituencies exceeding the > > number of SG Council seats) could have the effect of causing > > prospective new Constituencies to wonder how they can become involved > > if there are no remaining positions available. While the circumstance > > appears to be remote in todayâs environment, there should be a > > provision to address it before it occurs. If the Board elects to > > change the Council organization or voting structure then the Bylaws > > would have to be modified in any case. One alternative might be to > > move the language from this section to Article XX-Transition. > > > > > > Â§5.5 Issue: Transition language to map the existing Constituency > > seats to the new Stakeholder Groups. > > > > Staff emphasizes that this section of the transition article is only > > intended to map the existing Constituency seats (SGs do not yet > > formally exist) to the new Stakeholder Groups. > > > > > > Â§5.11 Issue: Voting thresholds for Policy Development Process > > > > As explained in an email sent to the Council list on Friday, 27 March > > by Ken Bour, the voting thresholds originally prescribed by the > > Working Group on GNSO Council Restructuring (WG-GCR) contained both > > PDP and non-PDP elements. In this re-drafting exercise, Staff > > recommended that the thresholds be parsed out as follows: the non-PDP > > voting thresholds will be contained in Council OR&P while the PDP > > thresholds will be included in Article XXTransition until such time > > as the Policy Process Steering Committee (PPSC) and Policy Development > > Process (PDP) Work Team (Jeff Neumann, Chair) have completed > > deliberations and are prepared to recommend a formal revision to Annex > > A of the Bylaws. Since the PDP thresholds are currently specified in > > Annex A, which is not being revised as part of the Council > > restructuring effort, Staff recommends that the new PDP thresholds > > should be included in Article XX vs. Council OR&P. Article XX is a > > âtransitionâ document only and, once the PDP voting thresholds are > > successfully relocated from Annex A to the Council OR&P (Staffâs > > recommendation), Article XX can be removed from the Bylaws in its > > entirety (assuming all other transition matters are completed). Below > > are the voting thresholds recast into the two groupings: > > > > Non-PDP: > > a) Elect Council Chair: requires 60% of both houses. > > b) Remove NCA for Cause: requires 75% of both houses (excluding the > > NCA subject to removal); subject to Board approval. > > c) All other GNSO Council Business (default): requires majority of > > both houses. > > > > PDP: > > a) Create an Issues Report: requires more than 25% vote of both > > houses or majority of one house. > > b) Initiate a PDP within Scope: requires more than 33% vote of > > both houses or more than 66% vote of one house. > > c) Initiate a PDP not within Scope: requires a vote of more than > > 75% of one house and a majority of the other house (âSuper > > Majorityâ). > > d) Approve a PDP without a Super Majority: requires a majority of > > both houses and further requires that one representative of at least 3 > > of the 4 Stakeholder Groups supports. > > e) Approve a PDP with a Super Majority: requires greater than 75% > > majority in one house and majority in the other house. > > > > The PDP thresholds (above) were taken from the consensus > > recommendation of the WG-GCR and have been approved by the Board. > > > > Staff recommends that, while the thresholds themselves are not subject > > to Council or community rewrite, the PPSC and PDP Work Team do have > > the goal of reengineering the entire PDP. If, in the course of those > > deliberations, it appears that some or all of the above thresholds > > need to be modified or recast, the Board will need to take those > > recommendations under advisement. > > > > Staff also notes that the Operations Steering Committee (OSC) and the > > GNSO Council Operations Team are working on developing the methods, > > procedures, administration, and tools (to become part of the Council > > OR&P) that will need to be in place when the Council takes its first > > bicameral vote, which could be as early as its June meeting in > > Sydney. > > > > > > General Comments > > > > Finally, contrary to a recent comment, Staff would like to clarify > > that it has not prejudged or âmade up its mindâ on any of these > > issues. As the GNSO Improvements Report noted: > > > > "Many details, of course, remain to be worked out concerning the new > > stakeholder structure for the Council, including the role of > > constituencies and/or interest groups within them. As noted earlier, > > we welcome the GNSO working with Staff to develop the appropriate > > Implementation Plan." (Board GNSO Improvements Report at page 33). > > > > In preparing the draft Bylaws, Staff has tried to track the > > implementation of GNSO Improvements and Restructuring to specific > > directions from the Board. We hope that this exercise serves to > > facilitate discussions on these important topics in order to resolve > > them in a timely manner. We welcome further conversation about how > > these elements might be achieved with different language. All Policy > > Staff involved can be reached via policy-staff(a)icann.org and > > +1-310-823-9358. > > > > Regards, > > > > Denise Michel > > Vice President, Policy

3 4

RE: [council] Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure
by Tim Ruiz April 6, 2009

April 6, 2009

That can be solved at the SG level, and actually should be in my opinion. Tim -------- Original Message -------- Subject: RE: [council] Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Sun, April 05, 2009 11:30 am To: "liaison6c(a)gnso.icann.org" <liaison6c(a)gnso.icann.org>, "council(a)gnso.icann.org" <council(a)gnso.icann.org>, policy-staff(a)icann.org Although it is correct that policy will be formulated in working groups, it is also important to remember that it is Council that will be deciding what policies to look at and formulating the charters of the working groups. The inability to speak on Council may well mean that the issues that are important to you do not get raised to the level where there is a WG to participate in. Alan At 05/04/2009 11:49 AM, Tim Ruiz wrote: >Thank you Avri. That is my view, and the RrC view as well. > >In addition to Avri's well reasoned comments it is my impression that >under this new structure the Council will be serving more in a >management role, as had been envisioned from the beginning but not yet >executed on well. The Working Groups is where the real policy work will >take place, and where it will be important for *voices* to be heard. If >that is true, then new constituencies will have the same opportunity as >all existing ones in that regard. Otherwise, giving such weight to >having a Councilor, seems backsliding on an issue that the new structure >is meant to address. > >Tim > > -------- Original Message -------- >Subject: Re: [council] Draft Revisions to the ICANN Bylaws Relating to >GNSO Restructure >From: Avri Doria <avri(a)psg.com> >Date: Sat, April 04, 2009 10:47 pm >To: "council(a)gnso.icann.org" <council(a)gnso.icann.org>, >policy-staff(a)icann.org >Cc: "liaison6c(a)gnso.icann.org" <liaison6c(a)gnso.icann.org> > > >Denise, > >Thank you for the detailed note on the Staff's position on these issues. > >In this not I want tomake a few points on the issue concerning the >changes to X.3.1 > >1. From the full report of the board (which is curiously difficult to >find on line: for those who need to get new copy it can be found at: >http://www.icann.org/topics/gnso-improvements/gnso-improvements-report-03fe… > >) >The Board requests the Council, with >support from Staff, to prepare suggested changes to the Bylaws, >within six months, regarding the Councilâs structure on the >basis of four broad stakeholder groups and voting practices >consistent with the principles outlined above. > >Thus unless the council agrees to the proposed amendments, they will not >constitute changes prepared by the council with the support of the >staff. In the case of the one council seat per constituency, I believe >the staff is advocating an position that can neither be warranted by the >Board recommendations nor by council decisions at this point. While the >recommendations made by the staff are appreciated as a starting point, >it is the GNSO council that must make the decisions. In reading your >discussion, I had the feeling you were presenting us with what you felt >was the only possible interpretation. I wish to take issue with this >assumption. > >2. I certainly see no language in the Board/BCG recommendations >requiring that each new constituency get a seat on the council. In fact >all of the discussions on seating in the council is at the SG level. >And my reading of the recommendations, as well as the length discussions >the council had with the BCG indicate the intention to de-link the seats >in the council from the constituency structure. Perhaps we will need to >get a ruling from the Board on this as it is difficult to proceed with >such diametrically opposed understandings on the board's decision. My >reading says that there is no direct linkage between the existence of a >constituency and a seat on the Council, though of course the SG has to >show that is is giving fair representation to all in the SG group - >whatever constituency they may be a member of or however many >constituencies they may be a member of. > >3. There was certainly no language indicating that once we got to more >then 6 constituencies in a non-contracted house or more then 3 >constituencies in the contracted house that we would need to restructure >yet again. I hope that we are successful in bringing new >constituencies into the process, and I think that a well defined WG >process will aid in doing so. But if the by-law change you and your >staff advocate were to be advanced, I believe that pain of an additional >restructuring as well as the waste of time and effort it would >constitute would work as a disincentive to the acceptance on new >constituencies. It would be as hard to add the 4th constituency to one >of the contracted house as it was to add new constituencies before the >reorg we are suffering through at the moment. I believe that creating >disincentives for the creation on new constituency was definitely not >something the Board was intending in its decision. > >4. While it is true that the reason for constituting new constituencies >is to allow greater voice, given the function of the future council as a >management group, and given that voice is dependent on WG participation >and not council membership, the subject of voice and a council seat are >orthogonal to each other. Thus I do not believe that a requirement for >one council seat for each new constituency can be backed up by an >interpretation of the requirements for change made by the Board. > >5. Finally it is up to the stakeholders charters, as approved by the >board to determine the process by which seats are allocated - this is >explicit in the BCG recommendation. Each of the SG has been given the >opportunity to design a fair and comprehensive system for doing so. The >Board will review each of these SGs in order to determine whether they >do or not. It seems to me that the right of self determination by the >SGs with the advice and consent of the Board must not be abrogated by >Policy Staff fiat. > >thanks > >a. > > > >On Tue, 2009-03-31 at 11:31 -0700, Denise Michel wrote: > > Many thanks to all of you who have already commented on the draft > > revisions to the ICANN Bylaws relating to GNSO restructuring that were > > circulated late last week to start community discussion (also > > attached). Your emails were particularly useful in getting everyone > > to focus quickly on several specific issues. In this message, weâll > > attempt to address a number of the specific comments made Friday and > > over the weekend to give you some background on our drafting thoughts > > to help further the dialogue. > > > > Article X: > > > > Â§3.1 Issue: This proposed Bylaws amendment assigns the > > responsibility for selecting Council representatives to the four > > Stakeholder Groups with the stipulation that each Board-recognized > > Constituency shall be allocated a minimum of one seat on the GNSO > > Council. > > > > This article seems to have garnered the most immediate attention and > > questions. Rather than prejudging this issue, Staffâs view was that > > this revision was entirely consistent with the GNSO Improvements > > Report, the Boardâs resolution, and various Board discussions > > to-date. Existing constituency Council seats are currently hard-wired > > into the Bylaws and no Board member or Board committee has suggested > > to us that this be changed. As discussed in greater detail below, > > elements in the Board-approved GNSO Improvements Report and in Board > > resolutions suggest that the role of Constituencies within the GNSO > > continues to be significant and merits ongoing support in the Bylaws. > > > > 1. The GNSO Improvements Report produced by the Board Governance > > Committee (BGC) and endorsed by the Board last June emphasized the > > continued primacy of the Constituency structure as a fundamental > > building block of the GNSO. The Report did not attempt to change the > > existing Bylaws mechanisms by which the Board evaluates and approves > > GNSO Constituencies, but instead recommended that the process be more > > fluid, open, and accessible. > > > > In fact, the Report contains many references to expanding Constituency > > involvement in the GNSO by (a) encouraging new groups to form, (b) > > providing those structures with standard âtool kitsâ of administrative > > services, (c) evening âthe playing fieldâ among constituencies, (d) > > creating general best-practice guidelines to ensure consistent > > operational practices across different groups, and (e) assuring the > > community that transparency, openness and fairness remain fundamental > > ICANN principles. The Report specifically states that: > > âIt should be noted that we view the new stakeholder structure > > primarily as a way to organize the Council. While it will also > > encourage the constituencies to maximize their common interests, it > > does not on its own change the constituency structure itself.â (Board > > GNSO Improvements Report, page 42). > > > > The ICANN Board, in its 1 October 2008 resolutions, reinforced its > > support for the following principles pertaining to the formation of > > the new Stakeholder Groups. The Board specifically requested that, in > > establishing the newly formed structures, all constituency members and > > other relevant parties comply with the Boardâs principles including, > > âThe inclusion of new actors/participants, where applicable, and the > > expansion of constituencies (emphasis added) within Stakeholder > > Groups, where applicable.â > > > > The GNSO Improvements Report anticipated the creation of a lightly > > structured Stakeholder Group (SG) organizational layer to be inserted > > between Constituencies and the GNSO Council with a primary > > responsibility to select/allocate/apportion GNSO Council seats among > > its Constituency members. It did not anticipate the elimination of > > Constituencies in favor of Stakeholder Groups, although some in the > > community now suggest that Constituencies may no longer be necessary. > > > > > > Staffâs position is not new and, at the Boardâs direction, Staff has > > made every effort to share its understanding with the community over > > the past six months through informal discussions with Constituency > > leaders and by providing sample organizational templates designed to: > > (a) help the community assess existing Constituency charters; (b) > > guide the development of potential new Constituency charters; and (c) > > assist community leaders as they fashioned new Stakeholder Group (SG) > > charters. > > > > 2. Second, among the stated goals of restructuring is to encourage > > the formation of new Constituencies to enhance the diversity of > > viewpoints in ICANN. As is true in the current Bylaws, Staffâs > > proposed amendment in this section continues to place the > > responsibility with the Board to determine if the viewpoint > > represented by the Constituency applicant is significant enough to be > > entitled to recognition and, thereby, a minimum of one Council seat. > > > > Based upon a few of the Stakeholder Group voting systems that have > > been submitted thus far, a newly approved Constituency may not gain a > > Council seat, which raises concerns about depriving the GNSO Council > > of the new voices that the Board formally recognizes. It is > > conceivable that, without the GNSO seat requirement, an incumbent > > interest group could control a Stakeholder Group and potentially > > prevent these new viewpoints from fully participating in the GNSO. > > Without the promise of being able to participate meaningfully at the > > Council level, Staff is concerned that prospective new organizations > > may not pursue the arduous tasks of organizing, petitioning, drafting > > a charter, and defending their viability in being formally recognized > > as a Constituency within the GNSO. Without Board protection in this > > potentially volatile and delicate vetting process, Constituencies in > > formation may cease to make the effort. If that reality should be > > allowed to unfold, the GNSO will have failed to achieve a vital > > element of the Boardâs vision. > > > > It has been suggested that there should not be a hard-wiring of > > Constituencies to Council seats and seat allocation should be a > > Stakeholder Group responsibility. We agree that SGs should have that > > responsibility, although not without any constraints, and this is > > reflected in these proposed Bylaws to spur consideration and > > discussion. The current allocation of Council seats to Constituencies > > has been hard-wired since 2003. It does not seem inconsistent to > > accord a similar right to each prospective new Constituency that is > > Board-approved. (See Article XX below for discussion of what happens > > in the future should we reach a point where the number of > > Constituencies exceeds the number of Council seats.) > > > > 3. Third, as it relates to the non-contracted party house, the GNSO > > restructuring removed three seats (collectively) from the Commercial > > Constituencies and provided a new Non-Commercial Stakeholder Group > > with six seats. The rationale for this shift was that this was > > appropriate because, with the proper outreach and recruitment > > activities, additional non-commercial Constituencies would be formed > > that would hold seats to represent different viewpoints on the GNSO > > Council. > > âa new non-commercial Stakeholders Group must go far beyond the > > membership of the current Non-Commercial Users Constituency (NCUC). > > We must consider educational, research, and philanthropic > > organizations, foundations, think tanks, members of academia, > > individual registrant groups and other non- commercial organizations, > > as well as individual registrants, as part of a non-commercial > > registrants Stakeholders Group.â (Board GNSO Improvements Report, page > > 32) > > > > Guaranteeing a Council seat to new Constituencies in this SG, which > > will have half of the Councilâs non-contracted party seats, provides > > assurance that diverse viewpoints will be represented and heard on the > > Council. > > > > > > Â§3.3 Issue: Procedures and voting threshold for removal of an NCA > > for cause. > > > > The language concerning removal of a Nominating Committee Appointee > > (NCA) for cause was included for completeness, but Staff is > > recommending that it (along with all non-PDP thresholds) be relocated > > to the GNSO Councilâs Operating Rules. The provision and voting > > thresholds, as specified for each house, were taken from the Working > > Group on GNSO Council Restructure (WG-GCR) Report approved by the > > Board in its 1 October 2008 meeting (see below). > > > > It is, Resolved (2008.10.01.09), the Board adopts all voting > > thresholds proposed in the WG-GCR Report. The Board requests that the > > GNSO develop any additional voting thresholds or categories that may > > be needed as part of its proposed GNSO Improvements Implementation > > Plan to be submitted to the Board for approval. > > > > This issue could conceivably be revisited in the context of the > > Council Operating Rules effort since it is anticipated that those > > rules would need to be approved by the Board before becoming > > effective. > > > > > > Â§3.6: Issue: Board Seats #13 and #14 > > > > As explained in the footnote to this section, the language presented > > in yellow highlight was recommended in the WG-GCR Report; however, it > > has not been approved by the Board. Staff is hoping to collect some > > final additional community feedback on the matter again this month and > > expects final Board action on this matter at itâs 23 April meeting. > > Once the Board has acted, this section will be amended to reflect the > > Boardâs decision as to the methodology and any other rules pertaining > > to these selections. I have asked Rob to make a final request to > > constituency leaders for feedback on the Board Seat issue and he will > > follow up on that mater this week. > > > > > > Â§3.8 Issue: Confusion as to whether the NCAs are appointed to > > each voting house by the Nominating Committee. > > > > Staff acknowledges that the original wording in (a) and (b) could be > > interpreted in a way that was not intended by the drafters. Staff > > recommends the following amendment to this section to avoid ambiguity > > as to how the NCAs are actually selected/appointed to each voting > > house: > > > > a. The Contracted Party House includes the Registry Stakeholder Group > > (three members), the Registrar Stakeholder Group (three members), and > > one Nominating Committee Appointee (NCA) for a total of seven voting > > members; and > > b. The Non-Contracted Party House includes the Commercial Stakeholder > > Group (six members), the Non-Commercial Stakeholder Group (six > > members), and one Nominating Committee Appointee (NCA) for a total of > > thirteen voting members. > > The assignment of each Nominating Committee Appointee to a voting > > house is determined by the GNSO Council Operating Rules and > > Procedures. > > > > > > Article XX > > > > Â§5.1 Issue: Provision that the Board resolves any condition in > > which the number of Constituencies exceeds the available Council seats > > in a Stakeholder Group. > > > > Staff refers to the explanation provided above in response to Article > > X, Â§3.1. > > > > Arguably, this language may not need to be expressed in the Bylaws; > > however, Staff believes that it is important to recognize formally > > that this potential condition (i.e. Constituencies exceeding the > > number of SG Council seats) could have the effect of causing > > prospective new Constituencies to wonder how they can become involved > > if there are no remaining positions available. While the circumstance > > appears to be remote in todayâs environment, there should be a > > provision to address it before it occurs. If the Board elects to > > change the Council organization or voting structure then the Bylaws > > would have to be modified in any case. One alternative might be to > > move the language from this section to Article XX-Transition. > > > > > > Â§5.5 Issue: Transition language to map the existing Constituency > > seats to the new Stakeholder Groups. > > > > Staff emphasizes that this section of the transition article is only > > intended to map the existing Constituency seats (SGs do not yet > > formally exist) to the new Stakeholder Groups. > > > > > > Â§5.11 Issue: Voting thresholds for Policy Development Process > > > > As explained in an email sent to the Council list on Friday, 27 March > > by Ken Bour, the voting thresholds originally prescribed by the > > Working Group on GNSO Council Restructuring (WG-GCR) contained both > > PDP and non-PDP elements. In this re-drafting exercise, Staff > > recommended that the thresholds be parsed out as follows: the non-PDP > > voting thresholds will be contained in Council OR&P while the PDP > > thresholds will be included in Article XXTransition until such time > > as the Policy Process Steering Committee (PPSC) and Policy Development > > Process (PDP) Work Team (Jeff Neumann, Chair) have completed > > deliberations and are prepared to recommend a formal revision to Annex > > A of the Bylaws. Since the PDP thresholds are currently specified in > > Annex A, which is not being revised as part of the Council > > restructuring effort, Staff recommends that the new PDP thresholds > > should be included in Article XX vs. Council OR&P. Article XX is a > > âtransitionâ document only and, once the PDP voting thresholds are > > successfully relocated from Annex A to the Council OR&P (Staffâs > > recommendation), Article XX can be removed from the Bylaws in its > > entirety (assuming all other transition matters are completed). Below > > are the voting thresholds recast into the two groupings: > > > > Non-PDP: > > a) Elect Council Chair: requires 60% of both houses. > > b) Remove NCA for Cause: requires 75% of both houses (excluding the > > NCA subject to removal); subject to Board approval. > > c) All other GNSO Council Business (default): requires majority of > > both houses. > > > > PDP: > > a) Create an Issues Report: requires more than 25% vote of both > > houses or majority of one house. > > b) Initiate a PDP within Scope: requires more than 33% vote of > > both houses or more than 66% vote of one house. > > c) Initiate a PDP not within Scope: requires a vote of more than > > 75% of one house and a majority of the other house (âSuper > > Majorityâ). > > d) Approve a PDP without a Super Majority: requires a majority of > > both houses and further requires that one representative of at least 3 > > of the 4 Stakeholder Groups supports. > > e) Approve a PDP with a Super Majority: requires greater than 75% > > majority in one house and majority in the other house. > > > > The PDP thresholds (above) were taken from the consensus > > recommendation of the WG-GCR and have been approved by the Board. > > > > Staff recommends that, while the thresholds themselves are not subject > > to Council or community rewrite, the PPSC and PDP Work Team do have > > the goal of reengineering the entire PDP. If, in the course of those > > deliberations, it appears that some or all of the above thresholds > > need to be modified or recast, the Board will need to take those > > recommendations under advisement. > > > > Staff also notes that the Operations Steering Committee (OSC) and the > > GNSO Council Operations Team are working on developing the methods, > > procedures, administration, and tools (to become part of the Council > > OR&P) that will need to be in place when the Council takes its first > > bicameral vote, which could be as early as its June meeting in > > Sydney. > > > > > > General Comments > > > > Finally, contrary to a recent comment, Staff would like to clarify > > that it has not prejudged or âmade up its mindâ on any of these > > issues. As the GNSO Improvements Report noted: > > > > "Many details, of course, remain to be worked out concerning the new > > stakeholder structure for the Council, including the role of > > constituencies and/or interest groups within them. As noted earlier, > > we welcome the GNSO working with Staff to develop the appropriate > > Implementation Plan." (Board GNSO Improvements Report at page 33). > > > > In preparing the draft Bylaws, Staff has tried to track the > > implementation of GNSO Improvements and Restructuring to specific > > directions from the Board. We hope that this exercise serves to > > facilitate discussions on these important topics in order to resolve > > them in a timely manner. We welcome further conversation about how > > these elements might be achieved with different language. All Policy > > Staff involved can be reached via policy-staff(a)icann.org and > > +1-310-823-9358. > > > > Regards, > > > > Denise Michel > > Vice President, Policy

1 0