[CWG-Stewardship] Fwd: [client com] FW: Revised Community Agreement Draft: 08-05-2016

Mon Aug 8 20:17:23 UTC 2016

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-stewardship/attachments/20160808/b094d3cb/attachment-0001.html>