ICANN ICANN Email List Archives

[soac-mapo]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [GAC] [soac-mapo] RE: fees

  • To: soac-mapo <soac-mapo@xxxxxxxxx>
  • Subject: Re: [GAC] [soac-mapo] RE: fees
  • From: Robin Gross <robin@xxxxxxxxxxxxx>
  • Date: Thu, 9 Sep 2010 10:21:08 -0700

A recommendation such as the one proposed below addresses the concerns raised that led to the creation of an "independent objector" -- such that one is not additionally needed. If we are giving a new (free) objection right to both GAC and to At-Large, we don't also need to create a 3rd body ("independent objector") to launch objections, given how ripe for abuse such an "independent" objector would be. GAC and At-Large are accountable to their members, that is an advantage over an "independent" objector who is accountable to no one.

Thanks,
Robin

On Sep 9, 2010, at 10:01 AM, Richard Tindal wrote:


Chuck,

I support the first recommendation. For clarity we should use the word 'objection' instead of 'dispute' and we should be explicit that it's only for Rec 6 objections. Perhaps these words:

"ICANN Advisory Groups should be able to file an objection based on Rec 6 without paying a fee and any responses to such objection would also be allowed without fees."

I'm not a fan of the CIST idea. On the surface it sounds sensible, but, I think it would be of unwieldy size (almost everyone will want to be on it) and I think the staff are well able to consult people/ groups when they need implementation advice. I'd rather we spend the remaining few days getting our recommendations as clear and numerous as possible.

Thanks

RT




On Sep 9, 2010, at 6:21 AM, Gomes, Chuck wrote:

It seems to me that there is quite a bit of support for a recommendation like the following: "ICANN Advisory Groups should be able to file a dispute without paying a fee and any responses to such disputes would also be allowed without fees." Does anyone object to such a recommendation? Please feel free to suggest edits.

Margie - Please capture this as a possible recommendation for the report.

I appreciate the excellent discussion on issues like this one including the debate on implementation details but I want to communicate a caution. I do not believe we have time to reach consensus or even rough consensus on very many details for our report. So my recommendation is that we consider a recommendation something like this: "The Rec6 CWG recommends that the ICANN New gTLD Implementation Team form a Recommendation 6 Community Implementation Support Team (Rec6 CIST) to provide input to ICANN Implementation Staff as they further refine implementation details for Recommendation 6." I would hope then that some members of the Rec6 CWG would volunteer to be a part of the Rec6 CIST and share the detailed ideas that have been discussed. This type of approach was used in the past by the GNSO to assist in the implementation of recommended policies.

Please let me know what you think of this approach.

Margie - Please list this as a possible recommendation for the report, understanding at this point in time that it does not yet have any support.

Liz - Considering Margie's heavy load, would it make sense to assign another Staff member to keep track of pending recommendations and group statements?

Chuck

-----Original Message-----
From: owner-soac-mapo@xxxxxxxxx [mailto:owner-soac- mapo@xxxxxxxxx] On
Behalf Of Evan Leibovitch
Sent: Thursday, September 09, 2010 8:24 AM
To: Bertrand de La Chapelle
Cc: Richard Tindal; soac-mapo
Subject: Re: [GAC] [soac-mapo] RE: Note of GAC position on paying for
objections


On 9 September 2010 04:03, Bertrand de La Chapelle
<bdelachapelle@xxxxxxxxx> wrote:

I tend to share Richard's angle here. GAC and ALAC are ICANN
structures and
it makes sense to use them in the process (this strengthens the
internal
coherence of the ICANN system). Their collegial nature would play a
role to
filter frivolous objections (Richard's comment regarding the possible
abuse
of this waiver) and at the same time could help solve the conundrum
between
the "S" word (Frank's perfectly correct remark) and Avri's concern
about
"denial of service attack".

I agree. Of course any country (as well as any province, state or
city) could file an objection, but that could go through the same
process as any other community objection.

I would just ask whether the GAC is able to react fast enough to be
able to launch an objection sufficiently early in the application
process of a contentious string.

There is however two questions : would a GAC and ALAC objection go to
the IO
(additional filter) or directly to the DRSP ? and second : how would
an
objection be formulated (in practical terms : how will it be drafted)
by the
GAC ?

Arguably, a slighly redefined IO could be *the* source of "the First
Look". One could assume that any objection that has gone through the
GAC or ALAC consensus process would have been sufficiently vetted for
global suitability, so it could bypass that step.


Finally : I think in a previous formulation for objections, it was
suggested
to say : "The Board chooses the DRSP". Does that mean that the Board
would
have to designate a specific DRSP each time ? I thought the idea was
to have
a DRSP designated once and for all (whether it is the ICC or not is a
separate point). On a side note, I find interesting that the DAG
presently
proposes that both current MaPo and Community objections be handled
by the
same DRSP.

I am hoping that this group will fine-tune the DRSP role so that the
group's members will not necessarily be sourced from the same pool
(ie, the ICC).

Considering our discussion regarding the applicability of community
objections to handle some individual government concerns, would it be
useful
to group the two types of objections under a single heading covering
1)
globally objectionable strings (whatever we call them) and 2)
community
objections ?

This is quite reasonable.

- Evan





IP JUSTICE
Robin Gross, Executive Director
1192 Haight Street, San Francisco, CA  94117  USA
p: +1-415-553-6261    f: +1-415-462-6451
w: http://www.ipjustice.org     e: robin@xxxxxxxxxxxxx





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy