April 2009 - council - lists.icann.org

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

April 6, 2009

At 05/04/2009 09:12 PM, Milton L Mueller wrote: >Alan: >There are arguments to be made on either side of this issue. At this >stage, that is not the point. The issue is whether one staff person >decides for us or whether ICANN follows its legitimate process and >allows the stakeholders in the GNSO and the Board to come to an >agreement on this. At 05/04/2009 09:31 PM, Milton L Mueller wrote: >Alan, please note that the NCSG charter NCUC proposed allows a 20% >minority within the SG to bind _all_ NCSG Council representatives to >support the creation of a WG on a topic that that minority supports. >This is either a 20% of the Policy Committee, which represents >constituencies, or 20% of the membership. > >(does anyone actually read the charters we are debating?) > >So minority viewpoints on policy can be represented quite well on >the Council without the distorted process of binding constituencies >to a specific number of Council seats. > >Perhaps Denise's comments were made in ignorance of this feature of >the proposal, because it completely refutes her arguments. However, >staff members involved in this discussion sat in and listened as the >NCUC meeting debated and discussed it in Mexico City, so I know that >Ken Bour at least is fully aware of it. > >Anyway, as I said before, I am happy to discuss and debate the issue >with you, Alan, and other legitimate stakeholders in the process. >But this is our debate and the Board's decision. The staff has no >business intervening in the debate the way it has; they are only >involved to facilitate our discussions and not to act as a >substitute for the Board. Milton, I was not arguing for or against ANY of the various positions. I was just responding to Tim's comment that since policy will be formulated in Working Groups, it is THERE that having a voice will be important. As true as that is, I was pointing out that having a voice (direct, indirect or whatever) in Council will ALSO be important. This is clearly a position that you agree with, since you are reiterating that in drafting the NCSG charter, the need to be heard on Council was factored in. Alan

1 0

RE: [liaison6c] Re: [council] Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure
by Gomes, Chuck April 5, 2009

April 5, 2009

I suggest that we do our own legal analysis like we did with the two versions of the DAG to identify exactly what issues must stay in the Bylaws and develop our rationale for that so that we can either demand that those stay in the Bylaws or insist on mitigating language. I am sure that Jonathan Spencer will participate on our part. Should we arrange a conference call of RyC attorneys? Jeff - do you want to do that? Chuck > -----Original Message----- > From: Neuman, Jeff [mailto:Jeff.Neuman@neustar.us] > Sent: Sunday, April 05, 2009 9:13 AM > To: avri(a)acm.org; council(a)gnso.icann.org; policy-staff(a)icann.org > Cc: liaison6c(a)gnso.icann.org; Gomes, Chuck > Subject: RE: [liaison6c] Re: [council] Draft Revisions to the > ICANN Bylaws Relating to GNSO Restructure > > All, > > My biggest issues, which I have explained to staff and my > constituency surrounds taking elements out of the Bylaws and > putting them into an Operating Rules document as has been > implied by many councilors as well as by staff. I understand > the view that it MAY provide for some flexibility, but taking > any elements of the PDP out of the bylaws has implications on > the contracted parties which MUST be fully considered by the > legal staffs on the registries/registrars and ICANN prior to > taking any such actions since our agreements refer to the > Bylaws for the policy process. > > Perhaps more importantly, by taking elements out of the > Bylaws, you are essentially removing those elements from the > Independent Review Process. The IRP is only for cases in > which the Bylaws are violated. If the elements are not in > the Bylaws, there is no review and hence NO ACCOUNTABILITY. > As we have seen in the XXX IRP, the ICANN staff considers the > IRP to be extremely narrow (Too narrow in my opinion). > Nonetheless, I for one do not want to take things out of the > Bylaws without a commitment hardcoded in writing that > removing them from the Bylaws would not remove them from the > IRP in cases of any violations by the ICANN. > > I cannot post to the Council list, but believe these points > should be made clear to all of the Council members. > > Jeffrey J. Neuman, Esq.: NeuStar, Inc. > Vice President, Law & Policy > > > The information contained in this e-mail message is intended > only for the use of the recipient(s) named above and may > contain confidential and/or privileged information. If you > are not the intended recipient you have received this e-mail > message in error and any review, dissemination, distribution, > or copying of this message is strictly prohibited. If you > have received this communication in error, please notify us > immediately and delete the original message. > > > > -----Original Message----- > From: owner-liaison6c(a)gnso.icann.org > [mailto:owner-liaison6c@gnso.icann.org] On Behalf Of Avri Doria > Sent: Saturday, April 04, 2009 11:48 PM > To: council(a)gnso.icann.org; policy-staff(a)icann.org > Cc: liaison6c(a)gnso.icann.org > Subject: [liaison6c] Re: [council] Draft Revisions to the > ICANN Bylaws Relating to GNSO Restructure > > > 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-improvement > s-report-03feb08.pdf > ) > 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 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 > >

2 1

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

April 5, 2009

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 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

1 0

Collaborative Communication: New gTLD Overarching Issues
by Glen de Saint Géry April 3, 2009

April 3, 2009

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/en/announcements/announcement-02apr09-en.htm Collaborative Communication: New gTLD Overarching Issues 2 April 2009 In response to the Public Comments regarding the draft Applicant Guidebook posted 24 October, 2008, (http://www.icann.org/en/topics/new-gtlds/comments-2-en.htm) ICANN has created a dedicated WIKI space entitled, "New gTLD Overarching Issues." This wiki will enable the community to view and post comments, upload proposals, documents and reports and leave feedback for ongoing dialogue related to the four overarching issues described in earlier postings: Trademark Protection TLD Demand and Economic Analysis Security and Stability: Root Zone Scaling Potential for Malicious Conduct The WIKI can be accessed at: https://st.icann.org/new-gtld-overarching-issues/index.cgi?new_gtld_overarc… Community members may also continue to provide feedback through the New gTLD Applicant Guidebook version 2 public comments forum that ends on 13 April, 2009 http://www.icann.org/en/topics/new-gtlds/comments-2-en.htm. Comments to the WIKI made on or before 23 May, 2009 will be considered for discussion in Sydney and the next version of the Guidebook. ICANN continues to engage in global collaboration with the many communities that have an interest in finding workable solutions on the outstanding issues in the New gTLD Applicant Guidebook. These collaborations include: the establishment of the Implementation Recommendation Team (IRT) on trademark issues, the request for a joint SSAC-RSSAC study on DNS stability and the commissioning of independent papers on economic and potential user abuse issues. The WIKI is intended to facilitate these discussions and the formation of additional independent thought on these issues ICANN will be participating in additional public consultations to discuss these issues. The dates and times will be announced shortly. After these collaborative efforts have been collated, the recommendations put forth will culminate with public discussions, the first of which will take place at the ICANN Meeting scheduled 21-26 June, 2009 in Sydney, Australia. These discussions are intended to arrive at a final version of the new gTLD implementation plan or Applicant Guidebook. Modifications to the implementation plan related to these overarching issues and embodied in the New gTLD Applicant Guidebook and registry agreement will be open to at least one more round of public comment and feedback in Q3 2009. New gTLDs and the Internet Openness Change Innovation After years of discussion and thought, generic Top-Level Domains (gTLDs) are being expanded. They will allow for more innovation, choice and change to a global Internet presently served by just 21 generic top-level domain names. A draft Applicant Guidebook describing the detailed application process has been developed with opportunities for public comment. Additional information on the Program can be found at: http://www.icann.org/en/topics/new-gtld-program.htm. ICANN is a not for profit corporation dedicated to coordinating the Internet's addressing system. Promoting competition and choice is one of the principles upon which ICANN was founded. In a world with 1.5 billion Internet users (and growing), diversity, choice and innovation are key. The Internet has supported huge increases in choice, innovation and the competition of ideas and expanding new gTLDs is an opportunity for more. Media Contact: Brad White Director of Media Affairs Tel: +1 202 429 2710 Email: brad.white(a)icann.org<mailto:brad.white@icann.org> Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

IDN gTLD Fast Track Drafting Team
by Glen de Saint Géry April 2, 2009

April 2, 2009

Dear All, FYI As discussed during the Council call last week, an IDN gTLD Fast Track Drafting Team drafting team mailing list has been created. Participants subscribed to the list: Edmon Chung -Team leader (Registry constituency) Chuck Gomes - (Registry constituency) Stéphane van Gelder - (Registrar Constituency) Adrian Kinderis- (Registrar Constituency) Mike Rodenbaugh - (CBUC) Avri Doria - GNSO Council chair Alan Greenberg - (ALAC) Mailing list address: Gnso-idng(a)icann.org With public archives at: http://forum.icann.org/lists/gnso-idng/ Please let me know who else would like to be subscribed to this drafting team. 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 Tim Ruiz April 2, 2009

April 2, 2009

Alan, I'll take back any attempt to debate the voting thresholds. We can leave that perhaps for the PPSC-PDP Work Team to clarify. So I'll just ask that you and Avri consider everything else I've said on the subject up to that point (and when I am talking about scope it is referring to the scope of the picket fence), and accept my amendment as friendly or not. Tim -------- Original Message -------- Subject: RE: [council] PEDNR Motion From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Thu, April 02, 2009 2:40 pm To: Tim Ruiz <tim(a)godaddy.com>,"GNSO Council " <council(a)gnso.icann.org> 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. - 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. 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 stated by ALAC in > > > > >its > requestÃÂÃÂÃÂÃÂ¢ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ, 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 > > > > >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

1 0

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

April 2, 2009

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. - 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. 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 stated by ALAC in > > > > >its > requestÃÂÃÂÃÂÃÂ¢ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ, 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 > > > > >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

2 1

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

April 2, 2009

To address the first part of you leading sentence: Yes, I think that these are the types of things that this group must look at. Given the business model that has developed around domain names, I don't think that we can afford not to, because then we are only addressing part of the problem. Council and the Board have already address PEDNR issues several times, and failed because each time, only a part of the problem was addressed. 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 stated by ALAC in > > > > >its > requestÃÂÃÂÃÂÃÂ¢ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ, 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 > > > > >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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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.greenberg@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 stated by ALAC in > > > >its requestÃÂÃÂ¢ÃÂÃÂÃÂÃÂ, 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 > > > >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

1 0

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

April 2, 2009

I have no problem omitting the details if that will not later result in the PDP group being told that they have unilaterally widened their scope. For the record, I still don't know how a PDP that is restricted to PEDNR can widen its scope by the reference to the RAA, but I have made my case and it is up to Council to decide. Regarding contractual terms, see my last note about resellers. Alan At 02/04/2009 02:16 PM, Gomes, Chuck wrote: >Alan, > >The purpose of PDPs is to develop policy not >work on contractual terms. The result of policy >development work may impact registry or >registrar contracts but that is not the purpose >and to focus directly on contractual terms diverts from that purpose. > >I agree with you that the process should be to >find the best possible resolution to the issues >defined in the SoW but that doesn't require any >reference to the RRA. Moreover, the Council has >another work effort that focuses on RAA issues >so there really isn't need to mix the two. If >any resolution recommended affects RAA work, so >be it, but that does not need to be a goal >because that is too broad and could unnecessarily expand the scope of a PDP. > >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 1:29 PM > > To: GNSO Council > > Subject: RE: [council] PEDNR Motion > > > > > > I guess I don't understand why we should restrict the group > > from making such a suggestion. The aim of the process should > > be to find the best possible resolution to the issues raised. > > > > That being said, I presented the outcome of the DT, and it > > was moved by Avri and I think seconded by you (Chuck). > > Motions to amend are certainly possible - specifically to > > replace "ICANN compliance obligations and possible RAA changes" > > with "and ICANN compliance obligations". > > > > Tim also made another substantive change that I would like to > > hear the rationale for. > > > > Alan > > > > At 02/04/2009 01:17 PM, Gomes, Chuck wrote: > > > > >Wouldn't we be better off avoiding confusing the PEDNR > > motion with RAA > > >issues and instead focus on the motion without reference to the RAA? > > > > > >Chuck > > > > > > > -----Original Message----- > > > > From: owner-council(a)gnso.icann.org > > > > [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz > > > > Sent: Thursday, April 02, 2009 12:03 PM > > > > To: GNSO Council > > > > Subject: RE: [council] PEDNR Motion > > > > > > > > > > > > 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.greenberg@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 > > > > > stated by > > > > > >ALAC in its requestÃÂ¢ÃÃ, s, 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 complialiance 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 > > > > > > > > > > > > > > > > > > > >

1 0

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

April 2, 2009

I guess I don't understand why we should restrict the group from making such a suggestion. The aim of the process should be to find the best possible resolution to the issues raised. That being said, I presented the outcome of the DT, and it was moved by Avri and I think seconded by you (Chuck). Motions to amend are certainly possible - specifically to replace "ICANN compliance obligations and possible RAA changes" with "and ICANN compliance obligations". Tim also made another substantive change that I would like to hear the rationale for. Alan At 02/04/2009 01:17 PM, Gomes, Chuck wrote: >Wouldn't we be better off avoiding confusing the >PEDNR motion with RAA issues and instead focus >on the motion without reference to the RAA? > >Chuck > > > -----Original Message----- > > From: owner-council(a)gnso.icann.org > > [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz > > Sent: Thursday, April 02, 2009 12:03 PM > > To: GNSO Council > > Subject: RE: [council] PEDNR Motion > > > > > > 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.greenberg@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 > > stated by > > > >ALAC in its requestÃ¢ÂÂ, 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 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 > > > > > >

2 1

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

April 2, 2009

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.greenberg@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 stated by ALAC in > > > >its requestÃÂÃÂ¢ÃÂÃÂÃÂÃÂ, 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 > > > >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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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.greenberg@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 stated by ALAC in > >its requestÃ¢ÂÂ, 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 > >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

2 1

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

April 2, 2009

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.greenberg@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 stated by ALAC in > > >its requestÃÂ¢ÃÂÃÂ, 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 > > >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

1 0

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

April 2, 2009

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.greenberg@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 stated by ALAC in > >its requestÃ¢ÂÂ, 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 > >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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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.greenberg@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 stated by ALAC in >its requestâ, 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 >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

1 0

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

April 2, 2009

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.greenberg@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 stated by ALAC in >its requestâ, 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 >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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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.greenberg@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 stated by ALAC in its request’, 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 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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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 <marika.konings(a)icann.org> Date: Thu, April 02, 2009 4:20 am To: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council <council(a)gnso.icann.org> Tim, please note that the recommendation you quoted from the Issues Report specifically relates to ‘the desired outcomes stated by ALAC in its request’, 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 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

2 1

Re: [council] PEDNR Motion
by Alan Greenberg April 2, 2009

April 2, 2009

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

2 1

PEDNR Motion
by Tim Ruiz April 1, 2009

April 1, 2009

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

1 0

RyC GNSO Travel Funds Position
by Gomes, Chuck April 1, 2009

April 1, 2009

The RyC approved the following position regarding travel funding for Sydney today. Travel Funding for Sydney - RyC Position 1 Apr 09 At this time the 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. Chuck

1 0