ICANN ICANN Email List Archives

[gtld-council]


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

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

  • To: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>, gtld-council@xxxxxxxxxxxxxx
  • Subject: RE: [gtld-council] Options regarding ICANN staff responsibility with respect to string criteria
  • From: Mawaki Chango <ki_chango@xxxxxxxxx>
  • Date: Thu, 1 Mar 2007 18:36:31 -0800 (PST)

[Note: It doesn't seem this went through on first posting; sorry if
double posting.]

We have been repeating pretty much the same thing as the bottom line
in David's reasoning, but because we are not registry or registrar,
you wouldn't listen to us (we do have lawyers, though, even though
I'm not one of them, and don't speak lawyers' language.)

The truth is, whether it is about personal data protection (Whois),
trademarks and "confusingly similar" TLD strings, or public morality,
there is no such thing as an "international law", much less a global
one. There are shared principles (this may be a cultural
issue/feature, or the consequence of legal cooperation among
different jurisdictions/countries, etc.) on the basis of which
related laws are quite similarly interpreted in their respective
relevant jurisdictions. On the long run, it gives the impression that
we are dealing with the same homogenous corpus of laws, or a single
and common source of laws, but in fact each court decision relies on
the provisions of legally defined and different jurisdictions.

As a consequence, it seems to me we are creating (and not realizing
yet) a new (?) genre or type of recommendations, one that I would
call the "recommendations of good intention" and guidance. In another
word, we just want to tell the community that ICANN will, in good
faith, observe the generally accepted legal principles, e.g., about
people's established rights, etc., and that we would like to urge the
applicants to take that into account for the strings they chose to
apply for. But we certainly don't want to go all the way to saying
that ICANN will have the final say about who has the right to what,
and why. Tricky, isn't it.

I suggested in Marina del Rey that this kind of recommendations (re.
confusingly similar and public morality) clearly reference the legal
basis/traditions/principles that ICANN is ready to endorse as its
norms of reference in making those decisions. You will not be
surprised if I say I don't considered that the ideal, but the only
compromise I see if the majority of the committee decide to keep
those recommendations with multi-legislation notions.

Another option would be to go ahead and clearly categorize, and
differentiate in our report, that type of recommendations as per my
characterization above (and as opposed to ICANN actionable
recommendations that will focus on its technical coordination
function.) In this case, they will be offered by the Council to the
Board as guidelines to guide their decisions in cases of uncertainty
*and where there is no legal challenge*. And if accepted by the
Board, they will serve to inform the public as part of the
guidelines/criteria they are invited to take into account for TLD
application in order to maximize their chances to win a string
*without challenge in courts*.

Of course a last option, and the best to some point of view which you
may not share, is to drop these multi-legislation based (and legally
ambitious) recommendations altogether.

Regards,

Mawaki 


--- Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx> wrote:

>  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
> > > 
> > > 
> > 
> 
> 




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

Privacy Policy | Terms of Service | Cookies Policy