Dear All, Following yesterday’s meeting, the staff support team has taken a stab at updating the exemption language in line with the discussion, see https://docs.google.com/document/d/1aFuwubJUiIbXjui9mT6M9n1iSd-N_puL/edit. Please review this language and take it back to your respective groups to see if this is an acceptable compromise factoring in the different views expressed. If you have any additional suggestions or proposed edits, you can include these in the form of comments in the google doc. If possible, please share your feedback well in advance of the next meeting which will be scheduled for Wednesday 15 February to allow for sufficient time for consideration and mailing list discussion. Thanks, Julie & Marika From: GNSO-SOI-TF <gnso-soi-tf-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Wednesday, 25 January 2023 at 18:41 To: "gnso-soi-tf@icann.org" <gnso-soi-tf@icann.org> Subject: [GNSO-SOI-TF] Action Items & Notes: SOI TF Meeting 25 January 2023 at 14:00 UTC Dear All, Please see below the action items and brief notes from today’s SOI Task Force meeting on Wednesday, 25 January 2023 at 14:00 UTC. These also are posted to the wiki at: https://community.icann.org/x/yYXOCg. Kind regards, Marika and Julie GNSO SOI TF Meeting on Wednesday 25 January at 14.00 UTC ACTION ITEMS: 1. Staff to revise the language to provide for general disclosure of the client without naming it, and further indicating whether the entity participates in other ICANN groups/processes; also to refine the examples. 2. SOI TF members to take the revised language back to their groups and provide feedback. 3. Secretariat staff to schedule the next meeting for Wednesday, 15 February at 14:00 UTC. Notes: 1. Welcome 2. Review updated exemption language (see https://docs.google.com/document/d/1aFuwubJUiIbXjui9mT6M9n1iSd-N_puL/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1aFuwubJUiIbXj...>) * From last call – make clear what “representative” means. * Some additional details re: exemptions with additional examples. Feedback/Discussion: * From Karen Day, RySG: In response to the edited language on exemptions – see attached. * Highest level the registries feel very, very strongly that there is not room for an exemption in the SOI process. Asked members in legal positions – there is nowhere that disclosure of a client with that client’s permission is prohibited. * Several example given of policy making, non-governmental organizations that have requirements for disclosure. * Susan Payne, IPC: * Seems that this disclosure is happening the “child” SOI – “by whom you have been appointed, specifically for this activity or as part of a larger engagement” * The language “as part of a larger engagement” is less clear, create ambiguity – either remove or change to “by whom you have been appointed to a role which encompasses this activity”. * Marika: Seems that “encompasses” could cover it. * James Bladel, RrSG: * Presented this to RrSG. * Generally agree with the RySG statement. * Exemption would seem to undermine the SOI process. * Could open potential scenarios organizations participating with a declared representative and multiple undeclared reps. * Undermines the ICANN goal of transparency. * If someone can’t participate because of the disclosure that’s the policy working as expected. * If there is a way we can address the concerns by tightening the language that is worth doing, but not with this exception. * Staff suggested action: Delete the language at the end in brackets and tighten the language to include, “by whom you have been appointed to a role which encompasses this activity”. * Susan Payne, IPC: * Only saw the RySG feedback yesterday, so IPC may need more time for comments. * Might be good to let the IPC respond more formally. * We are not the only group that has these concerns. * With respect to the RySG: Can’t compare governmental policy-making bodies and governmental lobbying group with ICANN participants. * IPC have this ethical obligation against disclosure, so being told they must disclose means they can’t participate. * Worth trying to breach this stalemate – need to look at the goal of this disclosure: Not necessary to know the entity – could know that it is a large brand owner for example, but not Disney; to know in general, their rationale. * Karen Day, RySG: * Would welcome more formal IPC feedback. * With regard to the feasible wording in the ICANN Bylaws, the RySG would agree that it’s not feasible to ask someone to violate ethics, but it is feasible to ask to get the consent of the person they are representing. If the client says no then the policy is working as expected. * Noted about getting at the intent – will bring that up with the RySG this afternoon. * James Bladel, RrSG: * Understand that any proposals have to be vetted by the groups. * Like the idea of declaring descriptor rather than the name of the client. * Also interesting to know whether the client doesn’t otherwise participate in ICANN groups. * Concerned that governments that are hostile to ICANN will participate by hiding behind a nondisclosure agreement. * Further refine the example and indicate whether the entity is participating in other SOs/ACs. * Susan Payne, IPC: * Not sure you can outright say that you know everything in which your client is engaging. * Might be able to find an example that is workable. Might be able to say, “to the best of your knowledge”. * James Bladel, RrSG: * The intent is to determine where there is more nefarious participation or actively working against a policy initiative. * Maybe say that I don’t have a contract with ICANN, nor am I seeking one. * I think we can all agree that we know this is already happening, but we shouldn’t determine that it is acceptable. * Don’t need to know the name of the entity, but in general what they are and whether they have or are seeking contracts with ICANN. * Karen Day, RySG: * Question: Do all groups have representation on the SOI TF? Answer: They do even if they aren’t participating in all meetings, they get the recordings and notes, and are on the mailing list. * Susan Payne, IPC: * Think it is unrealistic to expect representatives to have only one hat. * Even a contracted party could be both a registry and a registrar. * Nothing wrong with having multiple hats (clients representing) as long as this is clear. * James Bladel, RrSG: * One hat per group would be the expectation. * Prevent hat switching during a work stream. ACTION ITEMS: 1. Staff to revise the language to provide for general disclosure of the client without naming it, and further indicating whether the entity participates in other ICANN groups/processes; also to refine the examples. 2. SOI TF members to take the revised language back to their groups and provide feedback. 3. Consider updates in the recommendations report * Updated to reflect public comments and TF deliberations. * Need to include language on exemptions. * Still need use cases or include in implementation. Susan – Still plan to provide examples. Karen – Depends on what we are asking for in the SOI, particularly the exemption language. Leave it up to you to decide whether or not to wait. * May need some transition between old and new SOIs. Discussion: * Question: Is there any more to make this more universal? Answer: This is a GNSO-specific effort, but ccNSO and ALAC may also be looking at it. Might be a conversation with the Board. * This gets to how other SOs/ACs participate in GNSO processes. * Maybe the opportunity to raise this when the time is right. * 4. Confirm next steps * Schedule the next meeting in 3 weeks to allow time for TF members to consult with their groups. * Schedule at the same time and day. ACTION ITEM: Secretariat staff to schedule the next meeting for Wednesday, 15 February at 14:00 UTC.