Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

Members: please select all panelists and attendees in order for everyone to see chat.

I presume ‘cannot’ should be updated to ‘MUST NOT’?

It’s ok for us yes

Understood. Thank you Janis, and thanks to EPDP colleagues.

Note that the document on the right hand side was circulated by Caitlin yesterday.

We’ve tried to capture the different comments / concerns in the form of questions as there were a number of questions / comments that were related / similar.

Apologies fór being late - road closure....

No disagreement Janis. My proposal was to establish a starting point for this GNSO Standing Committee to make those determinations.

Agree with James.... even under this approach the standing committee would still need to make a determination as to what is policy.

Members: please select all panelists and attendees in order for everyone to see chat.

I am not trying to bypass Bylaws. We need to decide that SOME changes in what is centralized in the SSAD are NOT policy.

@Janis: +1. Policy development cannot take place outside of a proper process, as required by the Bylaws.

+1 Janis. Not every new use case implies policy change.

@AlanG: The thing is, that isn’t something we agree on - that some changes in what is centralized in SSAD are NOT policy. But this is an issue to be resolved in other recommendations imo, not here.

We will have an IOT. Can’t the IOT give that guidance in case of questions on what is policy and what not? IF the IOT cannot reach consensus, the question needs to go to the G-Council.

That is NOT what I am saying.

@Thomas - do you mean an IRT? I believe the idea is that the mechanism is for after the policy has been operationalized (after which the IRT is usually dissolved as they completed their work)?

Alan - that’s what you said, almost verbatim

lost Janis

I lost Janis for a few seconds too.

Janis is cutting out for me

me too

@Janis: you’re line is breaking up.

@Marika, sorry. Yes. IRT. You can always reconvene an IRT, right?

Seems better now

It would not be standing, but ad hoc just in case needed.

how is third party purposes not a policy issue?

I am saying that centralization/automation candidates which have legal validity and do not incur additional risk on contracted parties MEET the current policy that we are writing and can be implemented without changing the policy.

+1 Becky. Frankly, I am having a hard time imagining advice, guidance, or court cases that are not going to bring policy issues that will require interpretation, which must be done by a pop.

@Thomas: That is also what I was thinking. The IRT will remain in place for quite some time, until a policy effective date is reached. If additional implementation issues are identified after it is disbanded, the IRT can always be reconvened.

Janis, that is effectively the proposal I made at the outset.

@Thomas - an IRT is in principle only used to assist in the implementation of policy recommendations (to confirm that the implementation is conform the intent of the policy recommendations)

4.2. Notwithstanding Section 4.1 of this Appendix, Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful. Registrar and Registry Operator MUST provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.

@Marika. Understood. Amr seems to think along the same lines. We are looking for something more flexible yet with a mandate to create policy.

And I would add that I did work on big systems that were the focus of AI and so called “learning algorithms”. You cannot just let these things loose without policy guidance.

@Thomas - I think everyone has agreed that this should not be about creating new policy but it should be focused on implementation related issues.

Forgi4 my ignorance: what happens today if an established policy get ruled not compliant to the law? What is th exact process to update it? A full blown PDP or just an adaptation to the contracts?

*forgive*

When it comes to privacy law, ICANN has ignored it.

@Marika: focused on implementation, but could also identify issues that require policy development, and sending those to the GNSO Council to include in the issue scoping phase of a future PDP.

When It comes to IP law, pdps

@Hadia I do think there’s some disagreement about that and WHO gets to determine if it’s legally permissible, commercial and technically feasible...

@Marika, yes. That was my understanding, too.

There’s a lot more to ARS than just ICANN receiving the data to review. Outside vendors, testing the data (e.g. sending emails and making test phone calls) that might require just a little more consideration than just “give the data to ICANN automatically”

so are you saying that this committee will be able to make binding determinations as to what is legally permissible? or not permissible?

The law is a pretty wide ranging thing to consider…do we know how many different jurisdictions contracted parties operate in? How would that actually work?

As long as full consensus is required, fine

just wanted to point out that while Janis correctly stated my comment, the “but” that followed was omitted.

@Owen, yes, there may well be other considerations and they need to be considered. But the question is *IF* they are deemed to be legal and no liability. Why could it not be implemented.

@Margie- “expedited” in EPDP does not mean “faster pace”. What is means is “PDP without issues report”. So initially it is faster, but does not mean it works at a faster pace once in place.

@Becky in short, but out, Janis

:-)

@Alan- and again, how does this go through existing processes/structures, and ensure that contracted parties are not being bound to something that they might not find to be legally permissible?

UAM again? I thought that was dead and buried

+1 Becky

We prefer UAM, or as close to it as we can get, so long as it's legally sound.

Brian, as I understand it Becky said if a EDPB statement endorses some position that implies a major change, it has to be handled as a policy change, not a committee determination

and moving from SSAD to UAM would clearly be a major policy change

@brian, that is exactly why you would need to get back to a policy table, because moving from SSAD to UAM can’t be done without policy development.

@Milton: That was my understanding of what Becky said too, which I agree with.

+1 Becky. It seems that some are still holding out the hope for Rec 9 mechanism to provide an alternate PDP

right, Laureen. Would still need agreement on that in rec 9 mechanism

The UAM is a red herring. It required significant data flow from CT to the SSAD, and as legal as it might be in the presented scenario, it would be a CHANGE in what we are specifying in the current proposals.

I don't think I understood Becky correctly then.

Laureen - that’s essentially what I was proposing. The Standing Committee has a few functions (1) triggering a review in response to outside inputs (legal/regulatory changes, etc.). (2) determine whether or not the proposed changes are policy or implementation. (3) resolve the implementation issue itself, refer the policy recommendation to GNSO. I am baffled that this approach is causing controversy.

Janis is cutting out for me again

Lost Janis

Lost Janis

+1 Janis, so rec 19 mechanism can deem something a policy change, or an implementation adjustment based on new information. What matters now is that the group making those recommendations must have full consensus

@James, if you agree that SOME changes for centralization may be implementation, then we might be agreeing. If you claim that ALL such cases are policy, then not.

@Alan, we’re saying that the Standing Committee has to make a determination as to which is which. And the SC must have consensus to do either

I think I proposed that ALL changes that were incumbent on how the SSAD worked were implementation. And that changes that created new obligations for CPs was policy.

@Brian- just because there is legal guidance in one jurisdiction does not mean it’s legal guidance applicable to all jurisdictions. For example, Ireland might allow automated disclosure for a particular case, but that might conflict with German or Californian law.

Essentially - who is bound by the proposed change? SSAD = implementation, CP = Policy.

Why just the contracted parties? are you trying to erect some kind of new picket fence?

@Brian: Has the option to automate is not the same thing as being obliged to automate.

@Janis: +1

+1 Amr re: obligation to automate

+1 Janis

losing Janis

can't hear Janis

CAnt hear Janis either

Thanks, MarkSV. Was wondering if it was a problem on my end.

Perhaps Janis can reconnect with a more reliable device?

@Owen to your point, if it's not legal in a particular jurisdiction, the policy accounts for that with "legally permissible"

We are dialing out to Janis

yes

@Brian- my point is that just because a jurisdiction states a particular use can can be automated does not mean it thus gets automated completely (which your comment appeared to state). There still may need to be meaningful human review, and to create an automated system that accommodates variations between jurisdictions could be over engineered and cost prohibitive

Indeed, individual registrars who operate in limited jurisdictions may be able to/eager to “automate” quite a few things. The question which is still open is how this automation is going to take place, who does it, how they manage the oversight of that automated processing, etc.

If you know a practice is illegal in your jurisdiction, or if you know an actor does not have authority that you will recognize, you can filter.

@alan, that happens to me too when there is a glitch on blue tooth to earbuds

Amr , you certainly have my support on what you just said. NCSG will want to go into the details on each case

We can agree to automate a flat no. That is not the kind of automation or machine learning that third parties are looking for though....

@Janis: Neither have I.

I am really confused with what Amr is saying, the policy that says that whenever legally and commercially policy automation is possible. This has already been agreed.

@Hadia: I thought I just made it clear (again) that I don’t agree!!

Not the first time I’ve said this.

the policy that says that whenever legally and commercially permissible automation is possible. This has already been agreed.

Milton also sent an email saying the exact same thing I did.

Note that the default voting threshold for GNSO Council motions that are not explicitly called out in the Bylaws have a simple majority voting threshold.

The GNSO Council will require a simple majority vote on whatever the committee recommends.

@Alan: That is determined by the GNSO OPs.

What James said.

Council voting thresholds table: https://gnso.icann.org/en/council/appendix-1-gnso-council-voting-results-24oct19-en.pdf

As James said - a standing committee is not called out in the Bylaws as having a different type of voting threshold so it would be simple majority.

I do not believe that this is covered in current ops. I am open to being corrected.

@Alan - for everything not called out in the Bylaws, it is simple majority.

@Marika: +1

@Amr we have already agreed to a policy that says whenever legally and commercially permissible automation is possible. Are you withdrawing this agreement?

@Marc - the next text was in the same document with the questions that Caitlin circulated yesterday.

Would you like me to resend.

If you scroll further down beyond the questions you should see the text that Berry is displaying as the document is a copy of the one on the right side (just scrolled further down).

@Hadia: I can’t withdraw agreement to something I never agreed to. And you’re not addressing my point of disagreement. My disagreement is on adding use cases to the automation list as an “obligation” to CPs, as opposed to a “choice”. The NCSG has held this position consistently, so we’re not withdrawing anything.

@Amr forget the use cases. Do you agree to the policy ?

There is ZERO benefit to making a recommendation that the SSAD operator says they cannot implement.

I think Alan G's comment immediately above might help address Amr's question.

@Amr - the added text about ICANN org liaisons could be added to a paragraph about membership rather than the consensus paragraph. Would that help?

@Hadia: If the policy creates an obligation for CPs to adopt new use cases, then now…, which is pretty much what I’m hearing now. Can’t ignore the use cases.

@Caitlin: It would, but would still like more clarity on the intent of adding them to the proposal. Thanks.

@Hadia: Sorry…, there’s a “now” in my last comment, which should be a “no”. :-)

Generally, because if it’s going in to ICANN’s contracts you need the consent of the signatories to the contracts. If not, the RAA and RA start to look like unconscionable contracts, and could be challenged/thrown out.

The ICANN community cannot impose obligations on contracted parties without the agreement and consent of the contracted parties.

@Franck: Could you explain what you mean by “equally strong”?

@Amr the policy says "The EPDP team recommends that disclosure decisions MUST be automated where technically and commercially feasible and legally permissible" and this has been agreed upon by all groups a long time ago

@Hadia - please note that the automation recommendation is still under review. An updated version was circulated yesterday together with the agenda.

+1 Alan G

@Hadia: The NCSG never agreed to this.

"Unconscionable contracts" is a wild exaggeration, James. I don't think we're dealing with matters of conscience on this point.

@Hadia: We provided specific feedback to the recommendation on automation saying we can’t live with this.

Agree with Amr, we never agreed to that Hadia.

@Marika thank you for the reminder @Amr and stephanie we are still going to discuss this again tomorrow.

@Hadia: For the record, and so there is no confusion moving fwd, the NCSG position on this will not change.

“"Unconscionable contracts" is a wild exaggeration, James. I don't think we're dealing with matters of conscience on this point.” Given the history of the RAAs, I think it is an accurate description of ICANN’s historical pattern. Whether we are improving on the matter is still hanging in the balance frankly. A few last minute word changes and we are back there.

having ICANN liaisons as the operators of SSAD is important

Contracts that are so unbalanced as to be unfair? I don't think so.

yes

@Franck- any changes to the ICANN obligations for contracted parties will need the approval of the contracted parties. Full stop.

The list of metrics is the same since 1st draft.

@Berry: Thanks.

Contracts that denied the legal rights of registrants were unfair. That is a time honoured NCSG point of view, backed by the data commissioners on a number of occasions.

If I’m not mistaken, ALAC also commented on these bullets, saying that they are unclear, and need to be fleshed out.

I'd note, this will include "at a minimum" and really more implementation.

Updates seem fine to me

Likely there will be many metric types identified once the system is built.

I think we could live with the language on the screen.

My only concern here is that 3 months isn’t much time to get a whole lot of intelligence on this. It could take that long just to see some meaningful traffic patterns

Totally agree, 3 months is nothing.

Well at least it says no earlier than 3 months now…

@James: I agree. 3 months is nothing, and was a big problem with the GGP model. There would have been little useful data in just the first 3 months. imo, one of the advantages of a standing committee vs a GGP WG, which would eventually be disbanded.

Yeah, “no earlier” is better than “no later”. But I still think we’ll learn more in 6-12 months

“No earlier” sounds good.

True, people must be aware of the unreliability of the data though

No later than 12 months would be ok

@Stephanie I wouldn't consider it unreliable but maybe insufficient

I think we need six months to catch problems early.

Sure, we can have a baby while we wait

+1 Laureen

lol

lol thanks all

Unreliable for policy changes

Dashboard would be nice

To be constructive, I'm waiving my personal objection to CP veto in standing committee.

Thank you Franck!

See language highlighted by Berry on the screen that addresses this point.

So why are we departing from normal GNSO rules?

Please note that all this will still needs to be translated into a charter where further details can be worked out.

@Janis: I fully agree, and want to make this work…, but like I said, I know this is a sticky point for many within the NCSG.

Oddly enough, we have been arguing for years and seem to be…..outvoted.

I think it will be counterproductive to evade this important point….we will simply vote things down when they hit council.

So there needs to be balance.

As a reminder, latest version of automation can be found here (https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit) and yellow items here (https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit)

@Janis: It’s going to get all Lord of the Flies once you’re gone!! :-)

LOL

Thanks all. Bye.

@Marika the documents are not accessible