Re: [CWG-Stewardship] Fwd: [client com] FW: Revised Community Agreement Draft: 08-05-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@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@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@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@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@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@sidley.com <jhofheimer@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@nro.net [mailto:iana-ipr-bounces@nro.net] *On Behalf Of *Jorge Contreras *Sent:* Friday, August 05, 2016 10:01 AM *To:* iana-ipr@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-client
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Seun, Please see my responses inline. On Mon, Aug 8, 2016 at 1:58 AM, Seun Ojedeji <seun.ojedeji@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@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@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@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@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@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@sidley.com <jhofheimer@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@nro.net [mailto:iana-ipr-bounces@nro.net] *On Behalf Of *Jorge Contreras *Sent:* Friday, August 05, 2016 10:01 AM *To:* iana-ipr@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-client
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
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@gmail.com> wrote:
Seun,
Please see my responses inline.
On Mon, Aug 8, 2016 at 1:58 AM, Seun Ojedeji <seun.ojedeji@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@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@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@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@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@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@sidley.com <jhofheimer@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@nro.net [mailto:iana-ipr-bounces@nro.net] *On Behalf Of *Jorge Contreras *Sent:* Friday, August 05, 2016 10:01 AM *To:* iana-ipr@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-client
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
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@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@gmail.com> wrote:
Seun,
Please see my responses inline.
On Mon, Aug 8, 2016 at 1:58 AM, Seun Ojedeji <seun.ojedeji@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@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@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@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@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@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@sidley.com <jhofheimer@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@nro.net [mailto:iana-ipr-bounces@nro.net] *On Behalf Of *Jorge Contreras *Sent:* Friday, August 05, 2016 10:01 AM *To:* iana-ipr@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-client
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
participants (2)
-
Greg Shatan -
Seun Ojedeji