<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gtld-council] proposed new Rec. #21
- To: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
- Subject: RE: [gtld-council] proposed new Rec. #21
- From: Mawaki Chango <ki_chango@xxxxxxxxx>
- Date: Tue, 3 Jul 2007 12:36:19 -0700 (PDT)
Chuck,
I re-read your message with the subtraction you indicated, and:
i) correction: please replace in my previous message every
occurrence of "expert panel" by "dispute panel," which is more
correct since I was trying to refer to your previous mention of
a panel in this process;
ii) yes, it appears we're shooting in the same direction: the
need to balance the right base of a possible
challenger/plaintiff or any decision to reject a string with a
right base applicable to the defendant (i.e. the tld applicant.)
Except that we still haven't clarified whether ICANN's staff or
board is entitled, within the framework of this policy, to make
decisions about strings outside the scope of the technical
criteria provisions. If we leave that undefined or vague, then
we need to accept a language along the lines of the proposed #21
(it all depends on who gets to make the decision; if ICANN
doesn't make the decision, then it will not be exposed more than
it already is.)
Mawaki
--- "Gomes, Chuck" <cgomes@xxxxxxxxxxxx> wrote:
> Mawaki,
>
> I think I agree with everything you said. Upon re-reading my
> message, I
> think I confused matters by saying "it seems important to make
> sure that
> we are explicit about how the dispute panels evaluate all
> challenges."
> By that I did not mean being explicit about implementation
> details but
> rather explicit in the policy statement to ensure that all
> relevant
> rights contained in international principles of law should be
> applied in
> any rights based challenge. I suggest you ignore the second
> clause of
> my first sentence and focus on the rest of the message. I
> think it says
> things similar to what you said.
>
> Chuck Gomes
>
> "This message is intended for the use of the individual or
> entity to
> which it is addressed, and may contain information that is
> privileged,
> confidential and exempt from disclosure under applicable law.
> Any
> unauthorized use, distribution, or disclosure is strictly
> prohibited. If
> you have received this message in error, please notify sender
> immediately and destroy/delete the original transmission."
>
>
> > -----Original Message-----
> > From: Mawaki Chango [mailto:ki_chango@xxxxxxxxx]
> > Sent: Tuesday, July 03, 2007 12:55 PM
> > To: Gomes, Chuck
> > Cc: gtld-council@xxxxxxxxxxxxxx; Milton Mueller
> > Subject: RE: [gtld-council] proposed new Rec. #21
> >
> > Now it seems to me that we are mixing implementation
> language
> > with policy language. It seemed to me that the intent of the
>
> > policy we have agreed on, following NCUC-proposed amendment,
>
> > is to let the community know that decisions about strings,
> > _if any_, will take into encount or will not infringe
> > pre-existing rights that are enforceable and widely
> recognized.
> >
> > "If any" is the key phrase.
> >
> > Now of course, it depends on what level of the process and
> > what entity/authority will get to make that decision, if
> > relevant; this is a policy item under which that authority
> > will have to work. It may be that in a "normal" application
> > process and evaluation, there will not be at all the need to
>
> > make a decision about the string (because out of ICANN's -
> > board and staff -
> > purview) until an objection or challenge is filed. Then and
> > only then, the relevant authority for string challenges (an
> expert
> > panel?) will proceed under the guiding of this policy
> > recommendation. But we may not need this level of detail in
> > the policy rule. A more general level of language such as
> > "approval or rejection of a string must not infringe, etc."
> > is clear enough and a good fit for a policy.
> >
> > Now, if one wants to make sure that this is only a challenge
>
> > process issue, not ICANN's as organization (Board or staff -
>
> > and that's the meaning of the term 'ICANN' hereafter), one
> > may want the new gTLD policy to make allowance for the
> following:
> >
> > 1. Make sure that it is clear in the overall new gTLD policy
>
> > that ICANN do not have to, and will not make decision about
> > an application string, except for purely technical reasons
> > related to the DNS operation;
> >
> > 2. In that sense and as long as ICANN is concerned, any
> > string criteria policy pertains to technical creiteria
> policy
> > and should be dealt with in the relevant policy
> recommendations;
> >
> > 3. Then and beyond the above, ensure that the consideration
> > of any challenge/objection to the string by the relevant
> > authority (e.g., expert panel?), while trying to do justice
> > to the challenger (e.g., trademark holder) do not infringe
> > the rights of the applicant whenever they exist and as
> > recognized under international principles of law.
> >
> > In a nutshell, the best way to avoid further exposing the
> > organization ICANN to string-related disputes is first to
> > make it clear that it is not in the business of approving or
>
> > rejecting TLD strings per se. It then means these issues
> will
> > be dealt with by a different and _independent_ mechanism or
> > entity from ICANN, in conditions that are agreeable to both
> parties.
> >
> > I'm not expressing any preference, but just exploring the
> > logical options for what we want to achieve.
> >
> > Mawaki
> >
> >
> > --- "Gomes, Chuck" <cgomes@xxxxxxxxxxxx> wrote:
> >
> > > Hopefully our criteria for filing objections will be as
> clear as
> > > possible so we can minimize challenges that will not have
> > merit, but
> > > the reality is that there will probably be some, so it
> > seems important
> > > to make sure that we are explicit about how the dispute
> panels
> > > evaluate all challenges. If my understanding is correct,
> if
> > a rights
> > > challenge is submitted, the panel would evaluate the
> > challenge based
> > > on all rights that are based on international principles
> of
> > law. For
> > > example, if a string was challenged because of IP rights,
> that
> > > challenge must be evaluated based not just on IP rights
> > contained in
> > > international principles of law but also would be weighed
> > relative to
> > > other rights contained in international principles of law
> to the
> > > extent that rights may conflict. Is that consistent with
> > what others
> > > think?
> > >
> > > Chuck Gomes
> > >
> > > "This message is intended for the use of the individual or
>
> > entity to
> > > which it is addressed, and may contain information that is
>
> > privileged,
> > > confidential and exempt from disclosure under applicable
> law.
> > > Any
> > > unauthorized use, distribution, or disclosure is strictly
> > prohibited.
> > > If you have received this message in error, please notify
> sender
> > > immediately and destroy/delete the original transmission."
> > >
> > >
> > > > -----Original Message-----
> > > > From: Robin Gross [mailto:robin@xxxxxxxxxxxxx]
> > > > Sent: Tuesday, July 03, 2007 10:08 AM
> > > > To: Gomes, Chuck
> > > > Cc: gtld-council@xxxxxxxxxxxxxx; Milton Mueller
> > > > Subject: Re: [gtld-council] proposed new Rec. #21
> > > >
> > > > Thanks Chuck. Rec #21 does not create any different
> > > > exposure for the
> > > > board than Rec #3 does.
> > > >
> > > > We are trying to narrow the types of objections that can
> > > send
> > > > an applicant to an expert panel. Those objections based
>
> > > > solely on viewpoint would not go an expert panel because
> > > that
> > > > would not respect existing legal rights.
> > > >
> > > > Robin
> > > >
> > > > Gomes, Chuck wrote:
> > > >
> > > > >Thanks Robin.
> > > > >
> > > > >It seems to me that this wording may go counter to one
> of
> > > the
> > > > >objectives we have pursued for a long time on the New
> gTLD
> > > > Committee,
> > > > >that is to attempt to not put the ICANN Board in a
> > > situtation where
> > > > >they are overly exposed to risk. I understand Milton's
>
> > > > point that it
> > > > >may be impossible to limit all risk in that regard
> because
> > > > they are the
> > > > >overall coordinator of the process. But I still think
> we
> > > > should try to
> > > > >minimize their exposure. In that regard, would the
> > > > following word work for you.
> > > > >
> > > > >"The expert panel tasked with evaluating any string
> > > challenges filed
> > > > >must weigh an applicant's freedom of expression rights
> as
> > > > contained in
> > > > >internationally recognized principles of law."
> > > > >
> > > > >I suspect others may be able to word this better than
> me,
> > > > but my goal
> > > > >is focus on the what the expert panel would need to do
> > > rather than
> > > > >focus on the over all string selection process.
> > > > >
> > > > >Chuck Gomes
> > > > >
> > > > >"This message is intended for the use of the individual
> or
> > > entity to
> > > > >which it is addressed, and may contain information that
> is
> > > > privileged,
> > > > >confidential and exempt from disclosure under
> applicable
> > > law. Any
> > > > >unauthorized use, distribution, or disclosure is
> strictly
> > > > prohibited.
> > > > >If you have received this message in error, please
> notify
> > > sender
> > > > >immediately and destroy/delete the original
> transmission."
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: owner-gtld-council@xxxxxxxxxxxxxx
> > > > >>[mailto:owner-gtld-council@xxxxxxxxxxxxxx] On Behalf
> Of
> > > Robin Gross
> > > > >>Sent: Tuesday, July 03, 2007 8:42 AM
> > > > >>To: gtld-council@xxxxxxxxxxxxxx
> > > > >>Cc: Milton Mueller
> > > > >>Subject: [gtld-council] proposed new Rec. #21
> > > > >>
> > > > >>How about the following for a proposed new Rec #21?
> > > > >>
> > > > >>"The string evaluation process must not infringe the
> > > applicant's
> > > > >>freedom of expression rights that are enforceable
> under
> > > > >>internationally recognized principles of law."
> > > > >>
> > > > >>Thanks,
> > > > >>Robin
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|