Thanks, Karen.
All, please review the input provided by Karen as well as James in the google doc (https://docs.google.com/document/d/1aFuwubJUiIbXjui9mT6M9n1iSd-N_puL/edit).
Please come prepared to tomorrow’s meeting to consider the removal of the exemption language and/or further suggestions for how to address the concerns expressed. The proposed agenda is as follows:
- Welcome
- Consider input provided on SOI exemption language and path forward
- Outstanding items: SOI Samples
- Confirm next steps
Best regards,
Julie & Marika
From:
Karen Day <Karen.Day@sas.com>
Date: Monday, 13 February 2023 at 16:11
To: Marika Konings <marika.konings@icann.org>, "gnso-soi-tf@icann.org" <gnso-soi-tf@icann.org>
Subject: [Ext] RE: [GNSO-SOI-TF] Reminder: Re: For your review - updated SOI exemption language
Dear all-
As promised, I have taken the latest proposal discussed on our last TF call back to the RySG for feedback and to gage the support for such a compromise
- knowing generally (large brand in the entertainment industry) but not specifically (Disney or Fox, Sony or Apple) whom is being represented. Below are three comments which we believe state the RySG position and received full support with no voices speaking
against these positions:
- Hypothetically, if you have a working group or a PDP and there are four participants in the group that each identify as representing a large brand in the entertainment
industry, we will have no way of knowing if those four participants represent four different companies, or if they each represented the same company. This would be an easy way to exploit the loophole in the SOI disclosure requirements and stack the deck or
kill any progress the client does not like, since so much of what we do is based on consensus. There is no wiggle room on the question of disclosure, for all the reasons the RySG provided to the Task Force previously. We need the transparency the ICANN bylaws
require to protect the multistakeholder process and the policies that flow from it.
- Yes, it is relevant to know, referring to the examples used, whether the 2 Governments represented in the room are USA and Iran, or two govts not represented in
GAC, for instance. Yes, it is relevant to know, in a policymaking environment whether the brands being represented run a gTLD Registry or are participating in a process affecting the next round where they would apply for it. Same as knowing if, say, travel
expenses for any participant in any group have their expenses paid by a given ICANN participant…And I think that is where the distinction needs to be paid. We would require full disclosure if there were a client that is specifically paying them to participate
that working group on their behalf.
- For example, I am an attorney and I have provided services for several different entities that participate in the ICANN world (registries, registrars, brands, etc.).
I only need to disclose these entities if they are paying me specifically for the work I am doing in ICANN. To further illustrate the point, I have served as an expert witness in several IRPs so far. I do not have disclose them in my Council SOI (as an example)
because those companies are not paying me specifically (or even generally) for that policy work, they are paying me for being an expert witness. However, if I am hired by Dot ACME WIDGETS to participate in the Registries SG, I must disclose that to the Registries.
So, we are not telling the IPC that they have to name all of their clients, they only have to name the clients that are paying them to participate in the specific activity. And this by the way is NOT protected by the Attorney-Client privilege as many others
have pointed out.
Therefore, the RySG cannot support the language as currently proposed. While we feel there is no room for compromise on the issue of full transparency,
we again, want to reiterate that we are in no way asking anyone to violate any professional or ethical obligations. We are only asking for each representative to obtain an informed consent from their client to disclose their identity in relation to a specific
piece of ICANN work or in the absence of such consent, abstain from participation in respect of the ICANN bylaws and the multistakeholder process.
Look forward to speaking with you on Wednesday,
Karen
==========================================
Karen L. Day, ACP NCCP
Principal Legal Specialist
SAS Institute Inc., SAS Campus Drive, Cary, NC 27513
(919) 531-6016 direct
karen.day@sas.com
===========================================
From: GNSO-SOI-TF <gnso-soi-tf-bounces@icann.org>
On Behalf Of Marika Konings
Sent: Tuesday, February 7, 2023 6:25 PM
To: gnso-soi-tf@icann.org
Subject: [GNSO-SOI-TF] Reminder: Re: For your review - updated SOI exemption language
EXTERNAL
Reminder – please review the updated exemption language and share your feedback / comments in the document and/or mailing list well ahead of the meeting so that there is an opportunity for others to review and consider.
Thanks,
Julie & Marika
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 [docs.google.com] [nam02.safelinks.protection.outlook.com]. 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
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 [nam02.safelinks.protection.outlook.com].
Kind regards,
Marika and Julie
GNSO SOI TF Meeting on Wednesday 25 January at 14.00 UTC
ACTION ITEMS:
- 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.
- SOI TF members to take the revised language back to their groups and provide feedback.
- 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] [nam02.safelinks.protection.outlook.com])
- 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.
- 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.
- 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.
- 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.
- 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.
- 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”.
- 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.
- 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.
- 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.
- One hat per group would be the expectation.
- Prevent hat switching during a work stream.
ACTION ITEMS:
- 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.
- 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.