RE: [gnso-dt-wg] Rework of motion
Sorry for being so silent in this marathon discussion. With all the fun in Delhi, I contracted a bad flu, and by the time I got home, pneumonia, so I have been online only sporadically.
Along the way in this domain tasting roller coaster, I have been accused of being co-opted by the BC, IPC, Registrars and NCUC. So now I will support what Jeff is proposing.
Like Mike and Kristina, I would really like this whole process to be wrapped up quickly. However, I really do not want to proceed down a path that will result in nothing happening, or simply being bounced back to Council. And I think that proceeding without the real hope of a super-majority approval will lead to one of these - ultimately negating all of the work done to date, or at least taking a lot more time.
If the process that Jeff is outlining has a real chance of success by Paris, then I support it. I am making this statement without the benefit of ALAC consultation, but I will do that over the next week.
Regarding the comments below, the intent of the original motion, and the wording of the one I proposed last week made it made it clear that it was only applicable to those gTLDs that actually have an AGP.
Regarding future gTLDs, I spoke to Kurt Pritz in Delhi, asking if there has been any consideration to whether the contracts for the proposed new gTLDs would have an AGP. He said that there had not been any substantive discussion, but he thought they would be very amenable to a recommendation that if an AGP included, that it have limitations of the sort we are discussing now.
Alan At 24/02/2008 09:28 PM, Neuman, Jeff wrote:
The fact is that this draft motion/solution has NOT ever been out for public comment. In addition, this draft motion ignores the input from the registries that this particular one-size fits all solution does not work. For example: 1. Not all registries have the add grace period. 2. Not all registries have experienced tasting. 3. Some registries that have the add grace period have things like a free trial period and due to the nature of their registries, they are not susceptible to tasting. To answer the question is there a policy recommendation that we can find that would be acceptable to most if not all of the registries. To that, I believe the answer is yes. First, lets make sure that whatever the motion is, that it only applies to registries that actually have the AGP; Second, make sure that the solution is only needed when there is shown to be a problem of tasting. In other words, only registries where some level of tasting occurred must adopt this solution or alternatively propose something else that will have the effect of eliminating abuses of the Add Grace Period. This one is where we will need to find some objective formula to determine whether tasting is an issue. Taking .com, .net, .biz, .info, and .org and using them to determine this formula will be useful. As far as I can tell from reading the gTLD reports, I do not believe .asia, .aero, .cat, .jobs, .mobi, .museum, .pro, and .travel have seen tasting (some of which do not have the AGP). Of course, .tel and .post that have not launched yet have not seen these issues. Third, if a registry subsequently adopts the AGP, or falls within the category of the immediately preceding paragraph, it should have a period of ninety (90) days from the end of the first month in which such tasting is found to adopt the solution or submit a registry funnel request for an alternative measure that will curb the tasting. Of course, such funnel request is subject to public comment. Does this sound like a workable solution? Jeffrey J. Neuman, Esq. Sr. Director, Law, Advanced Services & Business Development NeuStar, Inc. e-mail: Jeff.Neuman@xxxxxxxxxx -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Rosette, Kristina Sent: Sunday, February 24, 2008 9:05 PM To: Liz Gasster; Gomes, Chuck; Mike Rodenbaugh; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion By my calculations, over 325 community members have provided input thus far. (I have assumed that 50% of the Supplemental RFI respondents, registrar straw poll respondents and submitters of public comment all participated in the general RFI and did not count them twice.) Anyone have different numbers? -----Original Message----- From: Liz Gasster [mailto:liz.gasster@xxxxxxxxx] Sent: Sunday, February 24, 2008 8:47 PM To: Gomes, Chuck; Rosette, Kristina; Mike Rodenbaugh; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion All, The three draft terms of reference that were suggested in the October 2007 Domain Tasting Outcomes Report that Chuck refers to below are copied for your reference. Liz 1. Review and assess all the effects of domain tasting activities that have been identified. 2. Judge whether the overall effects justify measures to be taken to impede domain tasting. 3. If the answer to 2 is affirmative, then consider the potential impacts of various measures on the Constituencies, and recommend measures designed to impede domain tasting. -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Gomes, Chuck Sent: Sunday, February 24, 2008 12:57 PM To: Rosette, Kristina; Mike Rodenbaugh; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion Thanks for the questions Kristina. I attempted to answer them as best I can below with the understanding that what I say is my personal interpretation because I have not cleared it with the RyC. I certainly encourage Jeff as the RyC representative on this WG to confirm or correct anything I say, and I of course will communicate any differences of opinion from RyC members if and when I become aware of any. Chuck -----Original Message----- From: Rosette, Kristina [mailto:krosette@xxxxxxx] Sent: Sunday, February 24, 2008 1:12 PM To: Gomes, Chuck; Mike Rodenbaugh; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion Chuck, It would be helpful to me (and perhaps others) if you could provide some clarification of one point made in the RyC constituency statement. Paragraph 3.1.2 states that "The RyC believes that a one-size-fits-all approach will not work for all registries and sponsors. The RyC therefore suggests that consideration of variations of this approach should be evaluated by individual registries and sponsors. It should also be noted that what is successful for one gTLD may not have the same results in another gTLD." Paragraph 3.2.1 indicates that this position has supermajority support within the RYC. I read this paragraph to mean that the RyC will not support a "one-size-fits-all approach." Is that interpretation correct? CG: Yes, but it may be helpful to qualify what I believe the position means. I attempt that below. If it is, I am having difficulty understanding how it is possible for the design team (or the Council, for that matter) to develop any policy, which will inherently be a one-size-fits-all approach", that will have any support from the RyC. (I am excluding "policies" that recommend no action be taken or recommend the status quo, namely, each registry do its own thing.) Is it possible? If so, I would appreciate some clarification. CG: If a policy is proposed that does not take into consideration the differences among registries and sponsors with regard to the AGP and the impacts the proposed policy might have on various registries and sponsors, then it is highly unlikely that the RyC would support the proposed policy. In my opinion though, that does not mean that the RyC would oppose any proposed policy. What I believe we are saying is that any such policy needs to adequately deal with any applicable differences that exist among registries and sponsors. In other words, the policy development process needs to attempt to address any applicable differences that exist among registries and sponsors. If that is done in a reasonable manner, then I do not think that the RyC would oppose any resulting policy recommendations on the basis of the issue of 'one size fits all'. The fact that this did not happen yet should not be taken as a criticism of the 'design team', because I do not believe they were tasked with developing policy but rather, as Avri pointed out, to suggest next steps forward. But, to the extent that the 'design team' takes on a broader role that includes proposing a possible policy, then it is essential that the one-size fits all issue be dealt with. This to me would best be handled by an open working group with clear terms of reference that delineate tasks as those suggested in the Domain Tasting Outcomes Report. Many thanks. K -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Gomes, Chuck Sent: Saturday, February 23, 2008 8:51 AM To: Mike Rodenbaugh; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion A few corrections and clarifications below Mike. Chuck -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Mike Rodenbaugh Sent: Friday, February 22, 2008 3:34 PM To: gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion I would prefer to vote on the proposal ASAP. Council has already decided not to have a Task Force, and had commissioned an open WG already, and has taken Constituency Impact Statements. This proposal has been thoroughly vetted through open process. I see no hope of coming to a solution that RyC will accept, because their position appears to be that ICANN can't make policy that binds them, unless they agree. And they haven't agreed to any policy development the last 3 years, except for newTLDs which will make them more money and Inter-Registrar Transfer which will save them money via less disputes. Seems to me that RyC is again trying to delay policy development for as long as they can, by throwing up bogus arguments about lack of process. CG: The open WG was an information gathering WG. The impact statements were not based on any policy recommendations developed by a PDP. What proposal was "thoroughly vetted"? Certainly not the proposal in the motion. While we won't have a SuperMajority (if indeed we even have a majority), it will be clear why, and the Board can do as it likes. And we can move onto other issues as we will have done our job. I simply have no confidence that 3 more months will produce anything different in the situation we have today. I have lost patience on this issue because the practice is so facially wrong and has garnered almost unanimous antipathy from the non-contracting community, yet Council have spun our wheels endlessly for about a year now, fruitlessly trying to do anything about it. Process like this gives ICANN a bad name. CG: Whether or not you think additional time will produce what you want is not the issue. The issue is whether or not we have a legitimate policy development process. -Mike Rodenbaugh -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Neuman, Jeff Sent: Friday, February 22, 2008 12:04 PM To: Avri Doria; gnso-dt-wg@xxxxxxxxx Subject: RE: [gnso-dt-wg] Rework of motion Avri, Is your question to the ICANN GC on whether the ICANN Board can act? If that is the question, the answer is yes. If your question is whether the ICANN's Board decision is binding on the registries, that is a totally separate issue. Irrespective of the answer, whether we call it a new PDP or jus opening a new WG, I guess I am neutral. I would just clarify that rather than having the WG determine a solution, in order to narrow that down, and speed up the times lines, I would propose that the WG just focus on the solution presented by the Design Team which I believe is the NeuStar/Afilias solution (unless people think that would be too narrow). Design Team -- Does this sound like a way forward? If so, I could take the substance of the motion that has been reworked (minus all of the Whereas clauses) and try to come up with a draft charter and proposed time-line to send to the group. (To that end, if someone has a form charter to use as a template, that would help). If not, I am sure I can wing it. Jeffrey J. Neuman, Esq. Sr. Director, Law, Advanced Services & Business Development NeuStar, Inc. e-mail: Jeff.Neuman@xxxxxxxxxx -----Original Message----- From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] On Behalf Of Avri Doria Sent: Friday, February 22, 2008 2:50 PM To: gnso-dt-wg@xxxxxxxxx Subject: Re: [gnso-dt-wg] Rework of motion Hi, Two quick comments: - The issue of whether this would or would not be a consensus policy is one for legal counsel. I can certainly check with legal counsel to find out the status of a decision according to 13f. - We are already in a PDP. As opposed to trying to begin yet another PDP, I would would think a suggestion for an open WG to come up with a solution that could get a supermajority would be a more feasible route. Assuming others in the DT and the council, agree with you. If this is the path the DT suggests, it would be good for the DT to propose the charter and timings. a. On 22 Feb 2008, at 13:45, Neuman, Jeff wrote: > > A couple of notes: > > 1. A majority of the Council as opposed to Supermajority is not > "deemed to reflect the view of the Council". See Section 12. > > 2. Yes, the Board can act, but again, that Board decision, in my view > (and in the view of the other registries) would not be binding on the > gTLD Registry Operators because that would not be viewed as "consensus > of Internet stakeholders". After all, if a majority is not even > deemed to reflect the view of the Council, then how can it represent a > Consensus of Internet stakeholder. > > 3. The reason I am using the phrase "consensus of Internet > stakeholders" is because that is the phrase that is used in the gTLD > contracts. See below which is taken from Section 3.1(b)(iv) of the > .com agreement (See > http://www.icann.org/tlds/agreements/verisign/registry-agmt-com-01mar06 > . > htm) which states: > > "Consensus Policies and the procedures by which they are developed > shall be designed to produce, to the extent possible, a consensus of > Internet stakeholders, including the operators of gTLDs. Consensus > Policies shall relate to one or more of the following: (1) issues for > which uniform or coordinated resolution is reasonably necessary to > facilitate interoperability, Security and/or Stability of the Internet > or DNS; > (2) > functional and performance specifications for the provision of > Registry Services (as defined in Section 3.1(d)(iii) below); (3) > Security and Stability of the registry database for the TLD; (4) > registry policies reasonably necessary to implement Consensus Policies > relating to registry operations or registrars; or (5) resolution of > disputes regarding the registration of domain names (as opposed to the > use of such domain names). Such categories of issues referred to in > the preceding sentence shall include, without limitation: > > Particularly important is the phrase "including the operators of > gTLDs". > Now before you try to argue that it is modified by the phrase "to the > extent possible", let me state that the following: > > 1. "To the extent possible" does not mean that if the registries are > on the losing side of the vote it is not "possible" to achieve gTLD > operator support for a proposal on domain tasting. > > 2. The gTLD Registries have indicated on a number of occassions that > we do believe a proposal to eliminate tasting (in TLDs where tasting > has > occurred) can garner the registry operators support. We are committed > to working with you to achieve that. We just need to find a solution > that takes into consideration the differences of each of the > registries. > > Now if we are done talking about process, lets get down to business: > > 1. There is a proposed solution on the table; namely I believe the > NeuStar/Afilias proposal (which by the way should be officially posted > for public comment today). > > 2. My recommendation is to take those proposals, get the GNSO Council > to initiate a PDP, and launch a Task Force (or Working Group) open to > the community whose sole purpose and charter is to study the > implications of this proposal. I would gladly help ICANN staff in the > drafting of that charter. > > 3. We follow the strict timing in the Bylaws on the formation of the > Task Force/Working Group, elect a chair, and get constituency > statements getting them to focus solely on the proposal. This should > be very easy, quick and painless. > > 4. Have a Task Force report that analyzes the constituency statements > and public input and modifies the proposal (if necessary). Put that > out for comment and draft the final report (all included in the > Bylaws). > > If we follow the strict timing in the Bylaws, which I believe we can, > we can have this done, wrapped up and to the Board within 90 days and > still before the Paris meeting. > > This will require some diligent efforts, but let's show that this is > possible. > > > Jeffrey J. Neuman, Esq. > Sr. Director, Law, Advanced Services & > > Business Development > > NeuStar, Inc. > e-mail: Jeff.Neuman@xxxxxxxxxx > > > -----Original Message----- > From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx] > On > Behalf Of Avri Doria > Sent: Friday, February 22, 2008 12:15 PM > To: gnso-dt-wg@xxxxxxxxx > Subject: Re: [gnso-dt-wg] Rework of motion > > > > On 22 Feb 2008, at 11:41, Rosette, Kristina wrote: > >> eff, good question. I'd appreciate clarification of that, too, to >> make sure we're all on the same page. The transcripts of the GNSO >> Council meeting and Thursday wrap-up are far from crystal clear. As >> for your other point, I had understood that the bylaws do not require >> supermajority support of Council before Board can vote. If there's >> language elsewhere that controls, I'd appreciate if you would point >> me in the right direction so that I'm working from the same baseline. > > Hi, > > As I read the by-laws, appended below, the Council does not need to > achieve a supermajority in order to forward on a decision (note 11b). > A non supermajority view, though, is treated differently by the board > (13b vs. 13f). > > In terms of this DT, the purpose is still to present a way forward for > the council to discuss. That can be a motion, a motion plus update of > constituency statements, or a WG charter. The motion can be based on > the reworked version Alan has presented, or another motion all > together, e.g. the elimination of a required AGP as was suggested by > many of the comments or some other motion. > > I think it is best if the way forward leads to a supermajority > position. If we can't get a motion that would be able to garner > supermajority support, then perhaps we need to do more work and a WG > charter might be the right way forward. > > a. > > > from the by-laws > ----------------------- > > 11. Council Report to the Board > > The Staff Manager will be present at the final meeting of the Council, > and will have five (5) calendar days after the meeting to incorporate > the views of the Council into a report to be submitted to the Board > (the "Board Report"). The Board Report must contain at least the > following: > > a. A clear statement of any Supermajority Vote recommendation of > the Council; > > b. If a Supermajority Vote was not reached, a clear statement of > all positions held by Council members. Each statement should clearly > indicate (i) the reasons underlying each position and (ii) the > constituency(ies) that held the position; > > c. An analysis of how the issue would affect each constituency, > including any financial impact on the constituency; > > d. An analysis of the period of time that would likely be > necessary to implement the policy; > > e. The advice of any outside advisors relied upon, which should be > accompanied by a detailed statement of the advisor's (i) > qualifications and relevant experience; and (ii) potential conflicts > of interest; > > f. The Final Report submitted to the Council; and > > g. A copy of the minutes of the Council deliberation on the policy > issue, including the all opinions expressed during such deliberation, > accompanied by a description of who expressed such opinions. > > 12. Agreement of the Council > > A Supermajority Vote of the Council members will be deemed to reflect > the view of the Council, and may be conveyed to the Board as the > Council's recommendation. Abstentions shall not be permitted; thus all > Council members must cast a vote unless they identify a financial > interest in the outcome of the policy issue. Notwithstanding the > foregoing, as set forth above, all viewpoints expressed by Council > members during the PDP must be included in the Board Report. > > 13. Board Vote > > a. The Board will meet to discuss the GNSO Council recommendation > as soon as feasible after receipt of the Board Report from the Staff > Manager. > > b. In the event that the Council reached a Supermajority Vote, the > Board shall adopt the policy according to the Council Supermajority > Vote recommendation unless by a vote of more than sixty- six (66%) > percent of the Board determines that such policy is not in the best > interests of the ICANN community or ICANN. > > c. In the event that the Board determines not to act in accordance > with the Council Supermajority Vote recommendation, the Board shall > (i) articulate the reasons for its determination in a report to the > Council (the "Board Statement"); and (ii) submit the Board Statement > to the Council. > > d. The Council shall review the Board Statement for discussion > with the Board within twenty (20) calendar days after the Council's > receipt of the Board Statement. The Board shall determine the method > (e.g., by teleconference, e-mail, or otherwise) by which the Council > and Board will discuss the Board Statement. > > e. At the conclusion of the Council and Board discussions, the > Council shall meet to affirm or modify its recommendation, and > communicate that conclusion (the "Supplemental Recommendation") to the > Board, including an explanation for its current recommendation. In the > event that the Council is able to reach a Supermajority Vote on the > Supplemental Recommendation, the Board shall adopt the recommendation > unless more than sixty-six (66%) percent of the Board determines that > such policy is not in the interests of the ICANN community or ICANN. > > f. In any case in which the Council is not able to reach > Supermajority, a majority vote of the Board will be sufficient to act. > > g. When a final decision on a GNSO Council Recommendation or > Supplemental Recommendation is timely, the Board shall take a > preliminary vote and, where practicable, will publish a tentative > decision that allows for a ten (10) day period of public comment prior > to a final decision by the Board. > > >