[CCWG-ACCT] Comparing single and multiple designators

Fri Oct 16 16:23:45 UTC 2015

Hi all,

Please note that the certification of this work was made in the break so I kindly ask Staff to take note of it and add it to the list of certified questions for control purposes.

Best regards,

León

> El 16/10/2015, a las 5:07 p.m., Thomas Rickert <thomas at rickert.net> escribió:
> 
> All,
> we have been approached with some questions about the differences between the Sole Designator Model and a Multiple Designator Model.
> 
> Please find below some responses from our lawyers.
> This is certainly not all there is to say, but we hope is helps advance our discussion.
> 
> Best,
> Thomas
> 
> 
>> 
>> We understand questions are being asked about whether a single or multiple designator model is “better.”  Which model better fits the interests of the ICANN multistakeholder community is not a judgment for counsel to make: it is for CCWG and the ICANN community to decide.  Our role is to provide information about the legal implications so that you can make an informed decision.
>> 
>> Outlined below is a summary of the differences between a single designator model (or Sole Designator model – “SD”; referred to also as a Community Designator Model) and a multiple SO/AC designator model (“MD”) from a legal perspective.
>> 
>> ·       In the SD approach, the SD is an unincorporated association legal person with legal capacity and standing to enforce its rights, even if the participating SOs and ACs in the SD’s decision-making processes are not legal persons.
>> ·       In the MD approach, the enforceability of each SO’s and AC’s rights as a designator will depend (among other things) on that SO’s or AC’s legal personhood.
>> ·       In the SD approach, the SD would be the designator with the right to select and remove all directors, but it would do so based on direction from the appointing SO or AC, or through a NomCom-type process, or based on a community consensus mechanism, as required by the Bylaws. .
>> ·       In an MD approach, action to select and remove a director is directly undertaken by the single SO or AC that has that right. Any action requiring the SOs and ACs to act collectively such as recall of the entire Board (and to defer their individual decision rights to a community process) will require some mechanism to be developed to obligate each designator to coordinate its action with all others, complicating the MD option.
>> o   Contractual agreements will not be available to accomplish this unless the designators are all legal persons with the capacity to contract.
>> o   The Board recall function could be accomplished using pre-service springing resignation letters from each director as a condition to being appointed as a director.
>> o   The Bylaws amendment functions (Fundamental and Standard) will be more difficult to address; a legal person can be given the right to consent to bylaws amendments, but it’s not clear who this person could be in the MD structure if each AC and SO is not willing to become a legal person.  Perhaps a trustee for the community, or an unincorporated association to be developed?
>> ·       The MD structure is essentially what we have concluded ICANN has now, so it’s the closest of all models to the current structure.  (However, as we have noted in prior advice, amendments to the Bylaws are needed to clarify designator rights – and ensure that the Board cannot unilaterally amend the Bylaws to remove designator rights.)
>> ·       The SD structure represents a greater change from the current structure (though less than a membership model).
>> ·       Because the SD structure requires decision-making processes for the SD to be set forth in the ICANN Bylaws, it is relatively straightforward to include in those processes, where appropriate, opportunities for the broader community, beyond the existing SOs and ACs, to be consulted and heard.
>> ·       Opportunities for input from the broader community could also be developed for an MD structure, although no community input to individual MD decision-making processes have yet been discussed, let alone developed.
>> 
>> The list above is a short and broad summary.  It has not gone through our usual internal review processes due to the request for an immediate reaction.  We may have additional comments and insights if we applied those review processes, and would be happy to do so if asked.
>> 
>> Rosemary and Holly
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151016/c24cd364/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151016/c24cd364/signature.asc>