[CCWG-ACCT] [Acct-Staff] Comparing single and multiple designators

Grace Abuhamad grace.abuhamad at icann.org
Fri Oct 16 16:49:54 UTC 2015


The Legal wiki page has been updated: https://community.icann.org/x/OiQnAw

From:  <acct-staff-bounces at icann.org> on behalf of León Felipe Sánchez Ambía
<leonfelipe at sanchez.mx>
Date:  Friday, October 16, 2015 at 5:23 PM
To:  Thomas Rickert <thomas at rickert.net>
Cc:  ACCT-Staff <acct-staff at icann.org>, "Rosemary E. Fei"
<rfei at adlercolvin.com>, Holly Gregory <holly.gregory at sidley.com>,
Accountability Cross Community <accountability-cross-community at icann.org>
Subject:  Re: [Acct-Staff] [CCWG-ACCT] Comparing single and multiple
designators

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/af800269/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5108 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151016/af800269/smime.p7s>


More information about the Accountability-Cross-Community mailing list