[client com] Seun Ojedeji comments on Community Agreement (was: Revised Community Agreement Draft: 08-05-2016)

[Greg Shatan]

Here are Seun's comments.  Please read the thread from the bottom up
(that's easier than forwarding a series of emails).  I've retitled this
email to distinguish it from the several Arasteh-related emails.

Greg

---------- Forwarded message ----------
From: Greg Shatan <gregshatanipc at gmail.com>
Date: Mon, Aug 8, 2016 at 4:48 PM
Subject: Re: [CWG-Stewardship] Fwd: [client com] FW: Revised Community
Agreement Draft: 08-05-2016
To: Seun Ojedeji <seun.ojedeji at gmail.com>
Cc: "cwg-stewardship at icann.org" <cwg-stewardship at icann.org>


Seun,

Thanks, that's all very helpful.  Neither ICANN nor the EC is
perfectly-suited for the job, and you have identified several weaknesses
(or at least, questions that need answering) with regard to the EC.

Greg

On Mon, Aug 8, 2016 at 4:17 PM, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:

> Hi Greg,
>
> For some reasons, my handheld is refusing to do inline commenting. I will
> try to respond based on the number references.
>
> 1. I am referring to liabilities that could result to costs(like the one
> you pointed out), I am referring to the fact that members of the CCG will
> be volunteers hence should be empowered by a proper organisation with
> actual executive power not only because it's an indication of support to
> the work of the CCG but also a sign of commitment to the sustainability of
> the group. The other consideration is that we are entering into agreement
> with external entities (outside ICANN) and it will be appropriate for a
> proper organisation/entity to fill that role as the EC was not designed to
> go beyond ICANN remit. The EC though is indeed an entity, but it is at best
> a functional entity on paper and does not really have any proper executive
> sides to it. I actually have no idea of who will be signing if we decide to
> use the EC. Will it be leaders of SO/AC (which ofcourse also includes the
> numbers community?)
>
> 3. Yeah you are right, my bad; I did not pay attention to that part of
> your mail as it was hidden(read it from my handheld gmail client), so I
> just read your text and went to the attached file.
>
> 4. Okay that clears it, if that's the collective understanding of the OCs.
>
> Regards
>
> Sent from my LG G4
> Kindly excuse brevity and typos
>
> On 8 Aug 2016 3:39 p.m., "Greg Shatan" <gregshatanipc at gmail.com> wrote:
>
>> Seun,
>>
>> Please see my responses inline.
>>
>> On Mon, Aug 8, 2016 at 1:58 AM, Seun Ojedeji <seun.ojedeji at gmail.com>
>> wrote:
>>
>>> Hello Greg,
>>>
>>> Comments on the points below:
>>>
>>> 1. For me, it all comes down to who bears the liability ultimately. If
>>> ICANN would still agree to bear the liability by having the empowered
>>> community signs then that would be fine.
>>>
>> ​You didn't mention liability before.  Are you referring to Section 6 of
>> the Community Agreement?  Section 6.2 caps monetary liability at $1000.
>> I'm sure we can find some way to deal with that, but I'm not sure ICANN
>> would agree to some sort of blanket indemnification of the Empowered
>> Community's actions under the Community Agreement.  That said, I don't
>> recall if Empowered Community liability was mentioned in any of the EC
>> documentation; it would be worthwhile to see how that is dealt with there.​
>>
>>
>>> 2. Sure that would work as well, my intent is just for the 3 OCs to be
>>> in sync on happenings.
>>>
>>> 3. Actually you did not indicate in your initial mail that the draft was
>>> put up with the Trust lawyers in sync. Since they have also confirmed the
>>> text not to be limiting in the way I posited then that is fine.
>>>
>> ​I was forwarding an email from Josh Hofheimer of Sidley, which stated
>> This is an iterative version prepared jointly by counsel (Sidley) to the
>> CWG and counsel to the IETF Trust to reflect the 7-point discussion items."​
>>
>> ​ I thought that was a sufficient indication.​
>>
>>> 4. 2d does not allow that Greg. Here is relevant text. "....Trust shall
>>> not be required to make any additional inquiry
>>> regarding the authority or validity of instructions....."
>>> Anyway I will not fret on this as addressing point 2 would also make my
>>> concern in 4 more impossible to happen.
>>>
>> ​Seun, you are misreading this.  While the Trust is not *required* to
>> make an additional inquiry, there is nothing *prohibiting* them from
>> doing so; therefore, they are clearly *allowed* to do so.  If I have a
>> sign at my front door that says "Guests shall not be required to take off
>> their shoes before entering" that does not mean that guests must keep their
>> shoes on; it only means the guests have a choice in how to deal with their
>> shoes.  Here, the IETF Trustees have that same choice.
>>
>> Greg​
>>
>>
>>> Regards
>>> Sent from my LG G4
>>> Kindly excuse brevity and typos
>>>
>>> On 7 Aug 2016 10:26 p.m., "Greg Shatan" <gregshatanipc at gmail.com> wrote:
>>>
>>> Seun,
>>>
>>> To respond to your numbered points below:
>>>
>>> 1. *Signatory*.  There are actually quite good reasons to consider an
>>> entity other than ICANN and thus significant doubts as to the suitability
>>> of ICANN for the role.  First, ICANN is not controlled by the names
>>> community.  Second, while ICANN is (or will be) accountable (to an extent)
>>> to the global multistakeholder community after the Transition, that
>>> accountability is very much a work-in-progress (as the two-year work of the
>>> CCWG-Accountability and the many WS2 tasks amply evidence).  Third, ICANN
>>> will be signing the License Agreement as the IANA operator; it would be
>>> rather peculiar for the same entity to sign the Community Agreement as the
>>> names community, given the interrelated nature of the two agreements, and
>>> particularly considering that one of the roles of the names community in
>>> this whole relationship is oversight of the IANA operator.  Fourth, the
>>> names community would need to figure out a method and process to cause
>>> ICANN to act on its behalf (and not on ICANN's own behalf) if any actions
>>> were required as party to the Community Agreement.  A reasonable candidate
>>> for this role is the Empowered Community entity.  It does not raise any of
>>> these concerns, and should be seriously considered as the signatory to the
>>> Community Agreement.  I'm not preempting discussion of ICANN as a possible
>>> candidate (indeed, it could be the better candidate on balance, and there
>>> could be "fixes" for these problems), but clearly there is a substantive
>>> discussion that must be had here.
>>>
>>> 2. *Notice to other Co-Chairs of Communications by a Co-Chair to the
>>> IETF Trust*.  This is a fair point; however, I would suggest that there
>>> should not be a requirement that the other Co-Chairs know about such a
>>> communication *before* the IETF Trust does.  A requirement for notice
>>> at the same time should be sufficient (of course, the Co-Chair could choose
>>> to communicate with the other Co-Chairs earlier, but that should be left to
>>> their discretion (and that of their community)).
>>>
>>> 3. *Delegation of Authority to the CCG*.  The delegation of authority
>>> here is very narrow.  The only authority being delegated is the authority "to
>>> determine if the IANA Services provided under the IANA Trademarks are
>>> consistent with the standards set forth by the Operational Communities."
>>>  Since these are standards set by the OCs, it's only logical that this
>>> authority should rest with the OCs and not the Trust.  The reason that this
>>> delegation is needed at all rest in U.S. legal requirements that the
>>> owner/licensor of a trademark to exercise (or cause to be exercised)
>>> "quality control" over the licensee's goods and services.  Since the OCs
>>> are already exercise oversight over the IANA Operator's provision of
>>> services (e.g., through the CSC and related processes), there's no need for
>>> any other active "quality control" to be exercised by the IETF Trust.
>>>
>>> 4. *Ability of IETF Trust to Make an Additional Inquiry in Reponse to
>>> an Instruction from CCG Co-Chair(s)*.  The IETF Trust absolutely has
>>> the option to make additional inquiries regarding the authority or
>>> validity of instructions or requests made by a co-chair.  It's just not
>>> *required* to do so.  I think this is clear from the current language
>>> of 2.3(d).
>>>
>>> Greg
>>>
>>> On Sun, Aug 7, 2016 at 9:19 AM, Seun Ojedeji <seun.ojedeji at gmail.com>
>>> wrote:
>>>
>>>> Thanks for the share Greg, it just amazes me the level of back and
>>>> forth between CCG and the Trust that has been formalised by this agreement.
>>>> This IPR thing is not a bone of contention at moment yet everything
>>>> functioned well. Over 18 pages just feels too unnecessarily "robust" for a
>>>> task that has been far from being noticed so far and IMO continues to
>>>> diminish the concept of "trust" that has made the Internet flourish thus
>>>> far.  Anyway it's okay if the Trust and the two other OCs are fine.
>>>>
>>>> That said, quick few points that I like to raise:
>>>>
>>>> 1. There is no doubt that the signatory for names would be ICANN. I
>>>> don't see any reason to consider any other entity for this purpose.
>>>>
>>>> 2. While I understand that the agreement is implementing the notion of
>>>> separation of the functions already implied in respective community
>>>> proposal, I think the OCs should try as much as possible to be in sync
>>>> hence I suggest communications from a OC chair should be known to other
>>>> members of CCG before transmission to the Trust(re: 2.3d). Ofcourse that
>>>> could be included in operating principles of CCG.
>>>>
>>>> 3. I am not a lawyer but reading section 3.1, it seem that section
>>>> technically seeds authority to CCG(which represents the respective
>>>> communities). Particularly the section below:
>>>>
>>>> ".....Accordingly, to the fullest extent permitted by applicable law,
>>>> the IETF Trust hereby delegates to the Operational Communities the IETF
>>>> Trust’s authority, as the record-owner of the IANA Trademarks,......"
>>>>
>>>> It will be good to know that is not the case.
>>>>
>>>> 4. I hope the authority implied in 2c,d does not mean that the Trust
>>>> cannot ask questions; While I recognise that it's rare and unlikely for a
>>>> co-chair to use the power accrued to them without consulting their
>>>> community. I feel not giving the Trust option to authenticate/validate
>>>> communication, opens room for hack. ;-)
>>>>
>>>> Regards
>>>>
>>>> Sent from my LG G4
>>>> Kindly excuse brevity and typos
>>>>
>>>> On 6 Aug 2016 11:24 p.m., "Greg Shatan" <gregshatanipc at gmail.com>
>>>> wrote:
>>>>
>>>> CWG,
>>>>
>>>> I am forwarding a revised draft of the proposed Community Agreement
>>>> relating to the IANA IPR.  In addition to any other comments you may have,
>>>> I draw your attention to the two specific items in the email below: (1)
>>>> identifying an entity to sign for the names community, and (2) providing a
>>>> brief description of the IANA Services used by the names community (
>>>> *see* Exhibit A for descriptions provided by the other communities).
>>>>
>>>> This will be the subject of further refinement by the IPR collaborative
>>>> group early in the week, with the goal of initiating a public comment
>>>> period as soon as possible after the CWG-IANA meeting on Thursday.
>>>>
>>>> Greg
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Hofheimer, Joshua T. <jhofheimer at sidley.com>
>>>> Date: Sat, Aug 6, 2016 at 4:55 PM
>>>> Subject: [client com] FW: Revised Community Agreement Draft: 08-05-2016
>>>> To: Client <cwg-client at icann.org>
>>>>
>>>>
>>>> Dear Client Committee,
>>>>
>>>>
>>>>
>>>> Attached please find a revised draft of the proposed Community
>>>> Agreement for your review and comment.  This is an iterative version
>>>> prepared jointly by counsel (Sidley) to the CWG and counsel to the IETF
>>>> Trust to reflect the 7-point discussion items.  To be clear, it is still a
>>>> work in progress, but we believe ready for the CWG to have an opportunity
>>>> for review.
>>>>
>>>>
>>>>
>>>> Two important issues to highlight:
>>>>
>>>> 1) the Names Community needs to determine who will be the signatory
>>>> party, acting on behalf of the Names Community, to the Community
>>>> Agreement.  For your information, the attached draft has the organizations
>>>> put forward to represent the Numbers and Protocols Communities; and
>>>>
>>>> 2) we need a brief description of the IANA services to be provided on
>>>> behalf of the Names Community.  The following high-level description was
>>>> included in a draft of the Naming Functions Agreement.  If this is
>>>> acceptable for including here is well, please advise (or we ask the Client
>>>> Committee to provide a sufficient description):
>>>>
>>>>
>>>>
>>>> The “*IANA Naming Function*” is comprised of:
>>>>
>>>> (a)             Management of the DNS Root Zone (“*Root Zone
>>>> Management*”);
>>>>
>>>> (b)             Management of the .INT top-level domain;
>>>>
>>>> (c)              Maintenance of a repository of internationalized
>>>> domain name tables and label generation rule sets; and
>>>>
>>>> (d)             Provision of other services related to the management
>>>> of .INT top-level domains, at ICANN’s reasonable request and at ICANN’s
>>>> expense.
>>>>
>>>> Please provide any comment or feedback as soon as practical, as we are
>>>> trying to finalize the draft for approval by the various stakeholders and
>>>> release for public comment by Thursday.
>>>>
>>>>
>>>>
>>>> Thank you in advance.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Josh
>>>>
>>>>
>>>>
>>>> *Joshua Hofheimer*
>>>>
>>>> *Sidley Austin LLP*
>>>>
>>>> *jhofheimer at sidley.com <jhofheimer at sidley.com>*
>>>>
>>>> *(213) 896-6061 <%28213%29%20896-6061> (LA direct)*
>>>>
>>>> *(650) 565-7561 <%28650%29%20565-7561> (Palo Alto direct)*
>>>>
>>>> *(323) 708-2405 <%28323%29%20708-2405> (cell)*
>>>>
>>>>
>>>>
>>>> *From:* iana-ipr-bounces at nro.net [mailto:iana-ipr-bounces at nro.net] *On
>>>> Behalf Of *Jorge Contreras
>>>> *Sent:* Friday, August 05, 2016 10:01 AM
>>>> *To:* iana-ipr at nro.net
>>>> *Subject:* [Iana-ipr] Revised Community Agreement Draft: 08-05-2016
>>>>
>>>>
>>>>
>>>> All – attached is a draft of the Community Agreement that Josh and I
>>>> have collaborated on over the past two days.  We believe that it reflects
>>>> the current requirements of the parties, and submit it for your review and
>>>> discussion.
>>>>
>>>>
>>>>
>>>> A clean version, as well as a marked version against the draft of
>>>> 07-30-16 (in PDF format) are attached.
>>>>
>>>>
>>>>
>>>> Please note a few items that still need to be completed, including the
>>>> description of the IANA Names Service, the identities of the CCG
>>>> representatives, etc.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Jorge
>>>>
>>>>
>>>>
>>>> Jorge L. Contreras
>>>>
>>>> Contreras Legal Strategy LLC
>>>>
>>>> 1711 Massachusetts Ave. NW, No. 710
>>>>
>>>> Washington, DC 20036
>>>>
>>>> contreraslegal at att.net
>>>>
>>>>
>>>>
>>>> The contents of this message may be attorney-client privileged and
>>>> confidential.  If you are not the intended recipient, please delete this
>>>> message immediately.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ************************************************************
>>>> ****************************************
>>>> This e-mail is sent by a law firm and may contain information that is
>>>> privileged or confidential.
>>>> If you are not the intended recipient, please delete the e-mail and any
>>>> attachments and notify us
>>>> immediately.
>>>>
>>>> ************************************************************
>>>> ****************************************
>>>>
>>>> _______________________________________________
>>>> Cwg-client mailing list
>>>> Cwg-client at icann.org
>>>> https://mm.icann.org/mailman/listinfo/cwg-client
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CWG-Stewardship mailing list
>>>> CWG-Stewardship at icann.org
>>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>>
>>>>
>>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-client/attachments/20160808/79a00c4a/attachment-0001.html>