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

Mon Aug 8 05:58:07 UTC 2016

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.

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.

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.

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/a2a12bfe/attachment-0001.html>