ICANN ICANN Email List Archives

[soac-mapo]


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

Re: [soac-mapo] charter and mission

  • To: Mary Wong <MWong@xxxxxxxxxxxxx>
  • Subject: Re: [soac-mapo] charter and mission
  • From: Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 14 Jul 2010 08:38:01 -0700

I would be surprised if GAC joined this group in any substantive way; they will 
want to reserve to themselves the ability to reject anything this group comes 
up with, but without them I worry that we may be wasting our time.  GAC has 
shown no compunction about rejecting something they don't like, even while 
refusing to come up with anything to take its place.  They have effectively 
arrogated a veto power to themselves, and they will reject the output of this 
group as well if they don't like the result. 

Does anyone have decent relations with the GAC to determine if they will join 
us?  They mentioned the idea positively in Brussels, in fact they complained on 
several occasions that they were not involved earlier in formulating policy.  I 
realize that including the GAC is a double-edged sword, but if we are concerned 
to produce something that doesn't meet with another flat rejection, it would 
wise to get them to participate now.  I would also say that it is the US 
government leading the objections, and therefore that is the particular player 
whose involvement we need.

Antony


On Jul 14, 2010, at 2:22 AM, Mary Wong wrote:

> Here's the thing with string and use, though - there are at least three, 
> increasingly expansive, ways to look at MAPO objections (even as currently 
> stated in DAGv4): just the string, the string plus user, and the string plus 
> use thereof/thereafter (Bertrand mentioned this during the GAC meeting as 
> well).
>  
> For those who do not think it either wise or feasible to remove MAPO entirely 
> from the new gTLD application process, are you comfortable with a contextual 
> examination (even if it is a panel comprised of "eminent jurists") in view of 
> ICANN's mandate?
>  
> As Evan (I believe) noted, there is no one from the GAC in this SOAC group at 
> the moment. In Brussels, they seemed at a loss as to whether and if they 
> could and should come up with an alternative recommendation to the Board. I 
> just don't see ICANN reversing course and agreeing to remove MAPO at this 
> juncture unless the GAC pushes for it (and as Avri and Philip have said, the 
> GAC may actually end up requesting something worse). That's partly why I 
> think we as a group should request that the consultation papers from the 
> "eminent jurists" consulted by ICANN be released to us, to figure out at 
> least whether the legal/normative issues that some of us have raised on this 
> list were addressed.
>  
> Mary
>  
> Mary W S Wong
> Professor of Law & Chair, Graduate IP Programs
> Franklin Pierce Law Center
> Two White Street
> Concord, NH 03301
> USA
> Email: mwong@xxxxxxxxxxxxx
> Phone: 1-603-513-5143
> Webpage: http://www.piercelaw.edu/marywong/index.php
> Selected writings available on the Social Science Research Network (SSRN) at: 
> http://ssrn.com/author=437584
> 
> 
> >>>
> From: "Philip Sheppard" <philip.sheppard@xxxxxx>
> To:   <soac-mapo@xxxxxxxxx>
> Date: 7/14/2010 4:47 AM
> Subject:      [soac-mapo] charter and mission
> 
> 
> I must say I am with Avri on this.
> 
> Instinctively, I see the need for some ICANN-based method to block an
> objectionable name.
> National law enforcement has failed to stop Internet crime, so it is a poor
> alternative.
> 
> And as said previously:
> a) the existence of a method will deter most cases of obviously objectionable
> TLDs, so the objection will not be needed.
> 
> b) when it does the issue is likely to be questionable and so must be 
> determined
> by a panel listening to arguments (which will address both string and use).
> 
> So, isn't the DAG4 proposal about right?
> The only action then is best endeavours to have a wise panel.
> 
> Philip
> 
> 
> 
> 
> 
> 
> 
> 



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

Privacy Policy | Terms of Service | Cookies Policy