ICANN ICANN Email List Archives

[soac-mapo]


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

RE: [soac-mapo] Terminology DRSP (and more on Rec 2.1)

  • To: "Avri Doria" <avri@xxxxxxx>, "soac-mapo" <soac-mapo@xxxxxxxxx>
  • Subject: RE: [soac-mapo] Terminology DRSP (and more on Rec 2.1)
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Wed, 15 Sep 2010 06:02:42 -0400

It appears to me that we may be converging on a possible recommendation
for which we may reach consensus.  With the understanding that I am
multitasking with IGF participation and the Rec6 CWG work so I may have
missed some points, here are the main points of what I see as a possible
way forward on this: 

1. The expert panel would give advice/recommendation regarding a Rec6
objection.
2. The Board would review that advice/recommendation and make a decision
on whether to approve the gTLD string.
3. A 2/3 majority would be required for a Board decision (pro or con).

Please correct me if I got any of this incorrectly or if something is
missing.  My intent was not to communicate the wording of the possible
recommendation because others have already done a good job in that
regard but rather to just summarize what I think the main elements of
the possible recommendation that seems to be emerging.

Does anyone in the CWG disagree with any of the three points or with the
overall recommendation?  If so, please speak up and describe your
concerns.

I know that many GAC members have been very involved with the IGF and it
has been difficult for them to keep up with the CWG list discussions,
but I hope that some GAC members can comment on the above.

Thanks for the excellent discussion of this.

Chuck


> -----Original Message-----
> From: owner-soac-mapo@xxxxxxxxx [mailto:owner-soac-mapo@xxxxxxxxx] On
> Behalf Of Avri Doria
> Sent: Wednesday, September 15, 2010 2:01 AM
> To: soac-mapo
> Subject: Re: [soac-mapo] Terminology DRSP (and more on Rec 2.1)
> 
> 
> this works for me.
> 
> and then the voting correlate would be that to bar any string a
> supermajority of the board would be needed.
> 
> with the assumption that if the appellant is either the GAC or ALAC,
> the board would then discuss their decision with them as required in
> the bylaw currently for GAC should they be requested to do so by the
> AC.
> 
> a.
> 
> On 15 Sep 2010, at 00:11, Milton L Mueller wrote:
> 
> > On the "advice" vs. "recommendation" issue, I think Mary got it
> exactly right here:
> >
> > For example, there's a difference (to my mind) between an expert
> opnion that "this series of words (i.e. the string) is contrary to a
> well-known principle of international law" and one that says "this
> string should not be approved because it is contrary to a well-known
> principle of international law". Wouldn't it be more appropriate for
> the expert opnion to be along the lines of the former, such that the
> Board then has to decide whether, in light of that finding, it will or
> won't approve the application?
> 
> >
> > In other words, the experts can tell the Board that in their opinion
> a string is clearly contrary to principles of int. law, possibly
> contrary, or clearly not contrary. But it cannot and should not say,
> "do not approve this string" or "do approve this string"
> >
> > That distinction may seem nuanced, but it really matters. It is the
> board making the decision, not the experts. This distinction is not
> quite captured, however, by the current proposal for 4.1, which says
> that the experts cannot provide advice or recommendations, which is
why
> I voted against it.
> >
> > As I have said before, whether you call the experts' report "advice"
> or "recommendation" or something does not matter much if the Board
must
> have a supermajority to kill an application based on an objection, and
> it must have that supermajority regardless of what the experts said.
> >
> > So in my opinion, the board should NOT vote to approve or discard
the
> decision handed to it by the experts. It should use the experts'
report
> as an input to its decision. The decision is its own.
> >
> > --MM
> >
> 





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

Privacy Policy | Terms of Service | Cookies Policy