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