RE: [gtld-council] Options regarding ICANN staff responsibility with respect to string criteria

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

 Thanks Chuck - such suggested wording improvements are very helpful.
Thanks for David's constructive feedback.

It is easy to say that any given wording is not good, it is much harder
to suggest how to make it better :-)

Regards,
Bruce Tonkin


> -----Original Message-----
> From: Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx] 
> Sent: Thursday, 1 March 2007 6:47 AM
> To: Bruce Tonkin; gtld-council@xxxxxxxxxxxxxx
> Cc: John Jeffrey; Kurt Pritz; Dan Halloran; Maher, David
> Subject: RE: [gtld-council] Options regarding ICANN staff 
> responsibility with respect to string criteria
> 
> Regarding "ii)        Strings should not infringe the 
> existing legal rights of
> others consistent with international law, recognising that 
> the applicant
> may have rights or legitimate interests in respect of the 
> string", David
> Maher shared some thoughts and made a suggestion on the RyC 
> mailing list
> that I think are helpful and he gave me permission to pass them on.
> 
> Quoting from David:
> 
> "As I said during the meeting, this invocation of "international law"
> does not make sense.  There is no "international law" of 
> trademarks, for
> example. There are a very small number of subjects where 
> there is a body
> of international law enforceable, through treaties, by national courts
> (or more rarely by truly international courts), but these subjects
> are not those likely to affect DNS strings (e.g. genocide). What the
> group may be struggling to say is something along the lines of: "the
> existing legal rights of others that are recognized or 
> enforceable under
> generally accepted and internationally recognized principles of law".
> This would cover, for example, the situation of "confusingly similar"
> trademarks. "Confusingly similar" is not a principle of international
> law. It is a principle of the trademark laws of nearly every 
> nation, and
> is recognized globally."
> 
> It seems to me that David's suggested rewording makes good sense.
> 
> 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 Bruce Tonkin
> > Sent: Saturday, February 24, 2007 1:58 PM
> > To: gtld-council@xxxxxxxxxxxxxx
> > Cc: John Jeffrey; Kurt Pritz; Dan Halloran
> > Subject: [gtld-council] Options regarding ICANN staff 
> > responsibility with respect to string criteria
> > 
> > Hello All,
> > 
> > In the discussion yesterday we recognised that ICANN staff 
> > responsibility with respect to the various string criteria 
> > could vary based on the specific criteria.
> > 
> > The options discussed were:
> > 
> > 
> > Option 1:  ICANN say nothing   
> > 
> > (ie ICANN merely sumarise public comment but do not attempt 
> > to use internal staff or paid external experts to provide 
> an opinion)
> > 
> > 
> > Option 2: ICANN identifies a possible issue, and ICANN files 
> > a complaint
> > 
> > 
> > (ie ICANN may use internal staff, as well as paid external 
> > experts if the staff think necessary, to provide a 
> > professional opinion on whether the string has an issue with 
> > respect to the string criteria, and ICANN could file a 
> > complaint with ICANN as the complainant with an external
> > dispute provider.   Note that this may be appropriate if 
> ICANN itself
> > was impacted by the choice of a particular string).
> > 
> > 
> > Option 3: ICANN identifies a possible issue, but relies on a 
> > complainant to file it formally
> > 
> > (ie ICANN may use internal staff, as well as paid external 
> > experts if the staff think necessary, to provide a 
> > professional opinion on whether
> > the string has an issue with respect to the string criteria.  
> >  It would
> > then be up to third parties to decide whether to formally raise a
> > dispute as a complainant.    This may keep ICANN focussed 
> on its core
> > mission and goals around technical coordination, and rely on 
> > an external
> > process to determine whether a string was permissible.   
> ICANN and the
> > applicant would agree to abide by the decision of the 
> > external process.)
> > 
> > Option 4: ICANN identifies and makes a decision, and the 
> > applicant can appeal
> > 
> > (ie ICANN may use internal staff, as well as paid external 
> > experts if the staff think necessary, to provide a 
> > professional opinion on whether
> > the string has an issue with respect to the string criteria.  
> >     ICANN
> > would then make a decision based on the analysis, and the 
> > applicant could appeal ICANN's decision through the normal 
> > appeal mechanisms provided in the ICANN bylaws.)
> > 
> > 
> > 
> > Applying these options to the string criteria:
> > 
> > i)  Strings must not be confusingly similar to an existing top level
> > domain 
> > 
> > There was some variation in opinion here between using option 
> > 3 or option 4.  It was thought that in obvious cases of 
> > strings that were confusing (particularly if this could be 
> > clearly identified as a potential security issue which is in 
> > ICANN's scope) then ICANN should
> > make a decision.   There were also cases where ICANN would 
> not want to
> > make a decision, but merely provide some professional advice.   Of
> > course the applicant would be free to respond to this advice 
> > as part of
> > the process.    The ICANN staff undertook to examine their legal
> > position on this point.
> > 
> > 
> > 
> > ii) Strings should not infringe the existing legal rights of others
> > consistent with international law, recognising that the 
> > applicant may have rights or legitimate interests in respect 
> > of the string 
> > 
> > 
> > The preference here was option 3 - with the requirement for a 
> > complainant to formally initiate a process through an 
> > external process (e.g UDRP like).
> > 
> > 
> > 
> > iii)        Strings should not cause any technical instability
> > 
> > 
> > The preference here was clearly option 4 as this is within 
> > ICANN's core mission.
> > 
> > 
> > 
> > iv) Strings should not be a Reserved Word 
> > 
> > 
> > The preference here was clearly option 4 as this is within 
> > ICANN's core mission.
> > 
> > 
> > 
> > v)  Strings should not be contrary to generally accepted legal norms
> > relating to morality or public order.  
> > 
> > The preference so far would be option 1 where ICANN would 
> > summarise public comment, but would not pay experts to render 
> > a professional opinion.  A complaint would need to be filed 
> > through an external
> > process.   This view was subject to ICANN identifying an appropriate
> > external process that would make use of existing laws common across
> > multiple countries with legal case history.   The words "generally
> > accepted legal norms
> > relating to morality or public order" were intended to make 
> > use of commonly used terminology that is interpreted by legal 
> > processes across a broad range of countries.
> > 
> > 
> > Regards,
> > Bruce Tonkin
> > 
> > 
>