ICANN ICANN Email List Archives

[soac-mapo]


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

Re: [soac-mapo] New 4.1 language

  • To: soac-mapo <soac-mapo@xxxxxxxxx>
  • Subject: Re: [soac-mapo] New 4.1 language
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Tue, 14 Sep 2010 11:25:30 +0300

Hi,

I agree with this, but have a question.

While the Board _may_ always, at its sole discretion, get external advise, do 
we want to advise that they _should_ do so in the case of the MaPO issues.

Also it then brings the question of voting thresholds into a different focus.  
My preference is that _all_ votes dealing with MaPo by the Board be on a 
supermajority basis.    Yes it is possible to have the burden fall on one tie 
breaker, but history in ICANN has shown that votes that are simple majority are 
deprecated.

a.

On 14 Sep 2010, at 08:56, Evan Leibovitch wrote:

> 
> 
> On 13 September 2010 17:59, Mary Wong <Mary.Wong@xxxxxxxxxxx> wrote:
> Would this work better as a possible replacement for the existing Rec. 4.1 
> language?
> 
> "In addition to the Board's ability to seek external expert advice under 
> Article XI.A of the Bylaws, it may appoint a third party entity to administer 
> the purely procedural aspects of an objection that has been filed. Such a 
> provider shall be appointed under contract for a fixed period of time 
> appropriate for the application timetable. It shall not provide expert advice 
> nor recommendations regarding the outcome of an objection, although it may, 
> if requested by the Board, assist in seeking appropriate international law 
> experts for particular objections. As in all other areas of ICANN policy, the 
> Board will ultimately decide whether to adopt or reject the advice of any 
> external experts it consults in relation to an objection.''
> 
> 
> This just helps make my case to dispense with Section 4 altogether.
> 
> In *all* its dealings the Board has the option of outsourcing procedural 
> matters or delegating them to Staff (or even hiring extra staff). Telling the 
> Board that it is able to do this is IMO simply stating the obvious (or at 
> least that which is already known to the Board).
> 
> The original intent of Section 4 was to define a DSRP. We've achieved fairly 
> good consensus that the result of this process should not be a DSRP (in the 
> sense used elsewhere in the DAG).
> 
> If all that is left to state is the the Board may, at its option, hire a 
> service provider to handle the paperwork and source experts for potential 
> use, that is both stating the obvious and possibly constraining the Board's 
> methods at an uncessesary level of detail. For example, the wording of 4.1 as 
> expressed above appears to prevent the Board from choosing to delegate the 
> procedural and expert-choosing tasks to staff should it wish. Why would we 
> want to place such a restraint?
> 
> We have enough of a chore in giving high-level direction to the Board. IMO 
> it's needless mandate-creep for us to be micro-managing how the board handles 
> the details.
> 
> If there must be a 4.1 I would word it far more simply, in a way that is 
> consistent with our architecture role rather than getting involved in detail:
> 
> 4.1: Ultimate decision on the admissibility of a TLD subject to a *** 
> objection rests with the Board alone and may not be delegated to a third 
> party. Under its authority to obtain independent expertise as stated in 
> Article XI A, the WG encourages the Board to contract or assemble appropriate 
> resources capable of providing objective advise on the applicability of 
> principles of international law, in regard to objections received through 
> this process.
> 
> The intent of this clause is to affirm that the decision rests with the Board 
> and nobody else, effectively abolishing the previous DAG role of the DSRP. In 
> its place, the Board is reminded of its existing capability to assemble a 
> panel expertise to help guide its decisions using the criteria we are 
> defining.
> 
> (*** --> whatever we call the "classification of objection formerly known as 
> MAPO")
> 
> - Evan
> 





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

Privacy Policy | Terms of Service | Cookies Policy