<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-dt-wg] Rework of motion
- To: "Mike Rodenbaugh" <mxrodenbaugh@xxxxxxxxx>, <gnso-dt-wg@xxxxxxxxx>
- Subject: RE: [gnso-dt-wg] Rework of motion
- From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Date: Fri, 22 Feb 2008 16:45:40 -0500
Mike,
I cannot let this note go unanswered, as much as I probably should just
ignore the non-productive response. Your comments about the registry
constituency are unfair, unfounded, disrespectful and utterly insulting.
The Registry Constituency took the lead on a number of issues over the
years including Whois, Transfers, IDNs, the Redemption Grace Period,
UDRP, the IGO Policy process, etc. as well as new TLDs.
That said, I am here on behalf of the RyC to get this done and get a
policy that does not waste anyone's time, including the ICANN Boards.
Isn't it better to solve the problem now before it gets to the Board,
then have the Board either (a) send it back to the Council or (b) vote
on it and not be able to enforce it.
I am offering to help and to help you get the support within the RyC. I
cannot guarantee you get the constituency support, but I can at least
attempt to get you there. I would have been here sooner to help, but
the role of the Design Team was not understood and I was not placed into
the group. I am sorry for that.
That said, I have volunteered my time, which by the way I do not have to
do because my proposal is already out there. I have nothing to gain for
my company by participating. I am sure they would rather not have me
work on this but work on revenue generating activity. I think this is
an important issue for the community and that is why I am here.
Neither the Working Group nor the constituencies ever commented on the
current proposal on the table. That is a problem. Not only a problem
for this Design Team and the Council, but a problem for true bottoms-up
consensus building and for implementing a solution. And let me again
state for the record, that it is not bottoms-up process to have a design
team of 3 or 4 Councilors craft a motion for a solution that was never
vetted at all by the community. It would be bottoms-up, however, to
float the proposed solution by the community for their input and then
(and only then) subject to any necessary modifications have that voted
on by the Council.
So let me ask the question. Does the Design Team support moving forward
with a working group proposal or equally suitable mechanism to follow
the right process or not. If not, I guess I will not be needed on this
Task Force. I will not contribute to a motion to be voted on by the
Council that has not followed any true bottoms-up process.
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: 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.
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.
-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.
>
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|