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: Richard Tindal <richardtindal@xxxxxx>
  • Date: Tue, 14 Sep 2010 08:18:54 -0700

Evan's language works for me

RT

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



On Sep 13, 2010, at 10:56 PM, 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