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

["Mike Rodenbaugh" <mxr@xxxxxxxxxxxxx>]

Agreed, thx.

 -----Original Message-----
From:   Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx]
Sent:   Wednesday, February 28, 2007 11:51 AM Pacific Standard Time
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
> 
>