Again, you use the term Filibuster, which is completely inappropriate.
Please answer the following simple question:
QUESTION: At what point in time was the proposal mentioned in the
"motion" by the Design Team EVER put out for public comment?
Even in looking at your recitation of history (which I am not going to
take the time to check the accuracy), the answer is clearly "NEVER".
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 Mike Rodenbaugh
Sent: Monday, February 25, 2008 12:11 AM
To: gnso-dt-wg@xxxxxxxxx; 'Council GNSO'
Subject: RE: [gnso-dt-wg] Rework of motion
Thanks Liz.
In response to this report four months ago, the Council essentially
voted to
handle these terms of reference itself, rather than form a Task
Force to
do
so. I believe we did this because a majority felt we had enough
evidence
about the effects, judged that the effects justify measures be taken
to
impede domain tasting, and had much information about potential
impacts
of
various resolutions but also would get Constituency Impact statements
about
such potential impacts. We then got those Impact Statements. The
Council
then voted to have an open, volunteer design team to suggest next
steps,
and
that team unanimously recommended a measure designed to impede domain
tasting -- which the Council should be deliberating, if we can get
past
the
process roadblock of the Registries.
How did we get here? Here's a brief history of the ICANN process
wrt to
domain tasting, and specifically wrt to the 'excess delete fee'
resolution:
PIR request to SSAC in March 2006,
http://www.pir.org/PDFs/SSAC-ICANN_ORG_Tasting_3-26-06.pdf
Sept. 2006, PIR proposal to implement 'excess delete fee service'.
Nov. 2006 the ICANN Board: Resolved, (06.84), the President and the
General
Counsel are authorized to enter into an amendment of the .ORG Registry
Agreement to implement the proposed excess deletion fee service
At least five ICANN public meetings and workshops on the domain
tasting
issue, links to full transcripts of those meeting are at this page,
http://public.icann.org/issues/domain-name-tasting:
* 27 June 2006: Domain tasting workshop
* 6 December 2006: Domain name marketplace.
* 25 March 2007: How the Marketplace for Expiring Names Has Changed
* 25 March 2007: Domain name secondary market
* 24 June 2007: Domain tasting tutorial
June 2007, PIR implements excess deletion fee, tasting immediately and
drastically reduced in .org
June 2007: In response to ALAC request and GNSO vote, ICANN staff
prepared
an issues paper on domain tasting, which discussed the PIR
implementation of
the excess delete fee.
http://gnso.icann.org/issues/domain-tasting/gnso-domain-tasting-report-1
4jun
07.pdf. The report also shows the ICANN General Counsel's opinion
that
policy development wrt to domain tasting is "within scope of the ICANN
policy process and within scope of the GNSO." This report also had a
public
comment period.
June 2007, GNSO voted to form a working group to examine the facts and
recommend further action, with a report created in October 2007:
http://gnso.icann.org/drafts/gnso-domain-tasting-adhoc-outcomes-report-f
inal
..pdf. The working group contained reps from all Constituencies and
from
other stakeholders. Their consensus report included discussion of
excess
delete fee (including PIR's implementation), suggestion of it as a
potential
resolution, and documented the widespread community discussion about
it
as a
resolution. This report included much public input both via an open
questionnaire, and also one designed by the Intellectual Property
Constituency for trademark owners.
October 2007, GNSO voted to move forward with the PDP by requesting
Constituency Impact Statements with respect to the information and
proposed
resolutions contained in the Outcomes report, including the excess
delete
fee. GNSO rejected option of forming a Task Force, deciding instead
that
the issue was ripe for Council deliberation and resolution. BC, NCUC,
ALAC
and Registrars Constituency each give view on excess delete fees. The
statements are incorporated in the "Initial Report"
http://gnso.icann.org/issues/domain-tasting/gnso-initial-report-domain-t
asti
ng-07jan08.pdf, which had a public comment period.
November 2007, GNSO voted to form a 'design team' to review all the
reports
and public comments, and recommend next steps in the PDP.
January 2008, Design Team of 3 Councilors and ALAC Advisor unanimously
agreed on proposed Council resolution recommending excess delete fee
for
all
registries with an AGP, which is the same proposal put forth by
Afilias
and
Neustar for .info and .biz. The Design Team finds this the most
reasonable
and potentially achievable compromise among the various options.
January 29, 2008, ICANN Board suggests action to address domain
tasting:
http://www.icann.org/announcements/announcement-29jan08.htm."; The
Internet
Corporation for Assigned Names and Numbers is looking to effectively
end
domain tasting with a proposal to start charging the annual ICANN
fee on
registrar domain registrations." It is unclear whether this will
actually
become part of the ICANN budget beginning July, 2008.
February 2008, Registries filibuster substantive Council
deliberation by
arguing there has not been enough process to address the proposed
Council
resolution. Registry Constituency representative argues that any
Council
resolution could not become Consensus Policy unless the Registries
Constituency agrees to the resolution.
Respectfully submitted,
Mike Rodenbaugh
-----Original Message-----
From: owner-gnso-dt-wg@xxxxxxxxx [mailto:owner-gnso-dt-wg@xxxxxxxxx]
On
Behalf Of Liz Gasster
Sent: Sunday, February 24, 2008 5: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 occasions 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.