Overall, this is great work. Comments from the IETF community folks are below.

== 2.3(e) ==

Change “If the IETF is …” to “If the IETF Trust is …”

Change “…determines that it is not advisable to accept such advice …” to “… rejects such advice …”

== 3.2(d) ==

This section needs to account for the fact that there will be multiple license agreements. Suggestion:

OLD the CCG co-chairs acting collectively (by unanimous action) shall have the right to instruct the IETF Trust to terminate the License Agreement with the then-current IANA Operator, as a whole.

NEW the CCG co-chairs acting collectively (by unanimous action) shall have the right to instruct the IETF Trust to terminate all License Agreement(s) with the then-current IANA Operator, collectively.

== 3.2(e)(i) ==

This sentence seems like it is missing a clause ("in the event" of what?):

"In the event that, after expending good faith efforts for a reasonable period of time, the IETF Trust, the prospective IANA Operator and the relevant Operational Community shall in good faith enter into non-binding mediation pursuant to the rules of the AAA (or other mutually agreed arbitral body with expertise in California law) for a period not to exceed ninety (90) days in order to attempt to come to agreement upon the terms of a License Agreement."

== 3.2(e)(ii) ==

This section needs to account for the fact that there will be multiple license agreements.

== 3.2(g) ==

The new sentence in this section says:

"However, the IETF Trust is not entitled to, and shall not, terminate a License Agreement except pursuant to the terms and conditions of the License Agreement (including Articles 6 and 7 therein)."

We think "the License Agreement" needs to be replaced with "that License Agreement" since there will be multiple License Agreements.

We also don't think this section should reference specific articles of any license agreement. It is possible that if the IETF Trust enters into a new license agreement with a new IANA functions operator in the future, that the termination conditions would not necessarily appear in articles 6 and 7 of that new agreement. It would be nice to avoid creating a dependency whereby the community agreement would have to be updated just because a license agreement got terminated or a new one got instituted.

== 3.4 ==

The phrase "on the one hand, and the IETF Trust” appears twice. Please delete one.

== 4.4 ==

Change "Protocol Community” to “Protocol Parameters Community” or “IETF Community” (three places)

How can the CCG acknowledge something when it is formed by this document? We realize that the OCs will name the CCG members, so it might be better to have the OCs do the acknowledging here. After all, the OCs are signing this agreement.

On Aug 5, 2016, at 10:01 AM, Jorge Contreras contreraslegal@att.net wrote:

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.

<Community-Agreement - 08-05-2016 marked against 07-30-2016.pdf><Community-Agreement - 08-05-2016 clean.docx>_______________________________________________ Iana-ipr mailing list Iana-ipr@nro.net https://www.nro.net/mailman/listinfo/iana-ipr