[CWG-Stewardship] Possible Definitions/Compositions of the "Names Community"

[Gomes, Chuck]

Thanks for getting this started Greg.  Here are my first reactions.

·         I think everyone one of these leave some members of the name community out.

·         Most of them are what I think are legitimate subsets of the ‘Names Community’.

·         It doesn’t seem to me that the ‘Names Community’ has to be a structure; in fact I think it may be difficult to find or create a structure inside or outside ICANN that would include all members of the ‘Names Community’.

·         A general definition may be the best way to go, one that doesn’t try to list specific members because as soon as we do that we will likely leave some out.

Here is my initial suggestion: “All current and future stakeholders of Internet domain names including individuals and organizations.”  I welcome critique of my thoughts and my suggestion.

Chuck

From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Greg Shatan
Sent: Wednesday, August 31, 2016 6:00 PM
To: cwg-stewardship at icann.org
Subject: [CWG-Stewardship] Possible Definitions/Compositions of the "Names Community"

On our last call, I volunteered to put together this email.

We need to define or identify the composition of the "Names Community" for purposes of the IANA IPR Community Agreement.  The role of the Names Community in this Agreement is outlined below.

Here are some non-exhaustive possibilities for the "Names Community," which I am throwing out without any judgment as to their appropriateness and in no particular order:


  1.  The CWG
  2.  All of the Chartering Organizations of the CWG (GNSO, ccNSO, ALAC, GAC, SSAC) but not acting through the CWG
  3.  An Implementation Oversight Team (IOT) (drawn in some fashion from the CWG and/or its Chartering Organizations)
  4.  GNSO and ccNSO
  5.  GNSO, ccNSO and ALAC
  6.  GNSO, ccNSO and GAC
  7.  GNSO, ccNSO, ALAC and GAC
  8.  Any other combination of some but not all Chartering Organizations
  9.  The CSC (representing those organizations and in the proportions represented on the CSC)
  10. The organizations contributing members to the CSC (but not necessarily acting through the CSC or in the proportions represented in the CSC)
  11. Any other combination of ICANN-created structures
  12. An existing non-ICANN-created structure
  13. A combination of ICANN-created and non-ICANN created structures
  14. A completely new structure
ICANN (the corporation) will be the signatory on behalf of the "Names Community."

The "Names Community" (and not ICANN the corporation) will need to be responsible for the substance of all Names Community actions under the Community Agreement and instructing its CCG representatives where appropriate, including:


  *   Appointing, removing and replacing three members of the CCG (Community Coordinating Group) representing the Names Community
  *   Appointing one of the three Names Community members as a Co-Chair and primary point of contact for the IETF Trust
  *   Determining whether the IANA Services are consistent with the standards set forth by the Names Community (determined through a "specified process of community engagement, feedback, contract and dispute resolution," which is expected to be the CSC, and when the time comes, the IFR process)
  *   Instructing the CCG Representatives
  *   Notifying the IETF Trust that the IANA Operator (initially, ICANN) is being replaced. (This would be the result of a SCWG decision.)
  *   Requesting that the IETF Trust enter into an IANA IPR License Agreement with a new IANA Operator and participating in these interactions/negotiations (particularly if the Trust or the Operator wants to vary the terms of the License Agreement) including mediation if the parties are unable to come to an agreement on terms of the new License Agreement
  *   Monitoring the IANA Operator’s use of the IANA IPR with respect to its designated IANA Service for the purposes of quality control under the License Agreement and notifying the IETF Trust of any failures or deficiencies in the quality of service provided by the IANA Operator that would violate such quality control provisions (again, this is likely to be CSC/IFR work in substance).
  *   Being consulted (through the CCG Co-Chair) by the IETF Trust if the Trust believes the IANA Operator has materially breached the terms of its License Agreement.
  *   Withdrawing from the Community Agreement
  *   Selecting or creating a new entity to replace ICANN as the signatory to this Agreement on behalf of the Names Community (which could be a responsibility of the CWG or some successor to the CWG)
  *   Determining a process for doing each of the above (to the extent it doesn't fall into an existing group with a process for doing things)
Please respond to this email with any thoughts you have on the possible ways (including additional ways) to identify/define the Names Community for this purpose, and with any questions you may have (and any answers you may have, as well).

Please keep in mind the relatively limited purposes for which this needs to be answered (just dealing with the Community Agreement) and the very limited time-frame we have to figure this out (at least, initially).

Thank you for your consideration of these issues.

Best regards,

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20160831/3dee37ba/attachment-0001.html>