ICANN ICANN Email List Archives

[gtld-council]


<<< 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 18:42:47 -0700 (PDT)

Chuck,

That last point relates to my previous post you said you concur
with, particularly the paras. 1, 2, 3 in its last part. This is
not about any specific phase of the application review process
(ARP). The question is from the first to the last step of the
ARP, does ICANN reserve the right to reject an application
string for reasons other than the stable operation of the DNS
(technical criteria)? If so, the intent and substance of #21
apply to ICANN;  but if any such decision about strings is to be
taken _only_ by a dispute panel _in case_ of
objection/challenge, then #21 will only apply to the dispute
panel or resolution mechanism. 

Either way, the substance of #21 is needed, as we all agreed in
San Juan, plus additional clarification in the latter -- re. "if
any such decision about strings is to be taken _only_ by a
dispute panel _in case_ of objection/challenge". I don't seem to
have seen any provision to that effect in this PDP, but please
correct me if I'm being betrayed by my memory.

The purpose of the whole point was to address your concern about
 (not) exposing ICANN. Please, if necessary, refer to my initial
post as mentioned at the start of this message. 

Mawaki

--- "Gomes, Chuck" <cgomes@xxxxxxxxxxxx> wrote:

> Thanks Mawaki.
> 
> I don't understand your last point: "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."  What part of the
> application review process are you talking about?  If you
> could provide
> an example or two, that might help.
> 
> 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 3:36 PM
> > To: Gomes, Chuck
> > Cc: gtld-council@xxxxxxxxxxxxxx; Milton Mueller
> > Subject: RE: [gtld-council] proposed new Rec. #21
> > 
> > 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 >>>

Privacy Policy | Terms of Service | Cookies Policy