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

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

30:05
who is „Netchoice“?

30:21
Steve DB?

30:22
@Volker, I just renamed.

30:27
Yes, Steve DelBianco

30:39
thx

32:16
https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit

41:37
I believe the footnote was added in response to a public comment which indicated that it was not clear what was intended with ‘automation’.

44:09
Good point Amr…we (RrSG) had envisioned a simple notification process AND not some sort of waiver process as you note

52:53
becaus

53:05
because we compromised?

53:24
There is an ENTIRE paragraph below specifically on the disclosure decision.

53:35
It is the language that was used in the Bird & Bird memo - my understanding is because the disclosure itself may include various processing steps.

53:37
Not even. A paragraph - a section

55:01
I note that my comments on resolving the conflict between 16.11 and footnote 3 were not addressed, and that we need clarity that SSAD human review might be required for specific use cases.

55:10
That’s not our understanding at all

55:14
Very frustrating

55:29
On the footnote, if there are no objections, we can remove it?

56:10
Yes please

56:39
Or the footnote could be clarified that the automated processing of disclosure decisions may involve non-automated review?

56:46
@Volker: +1

56:49
I'm happy to remove it. That still leaves the 2nd related issue.

59:06
Demonstrates to who?

59:44
If it’s demonstrates to ICANN, then 16.4 and 16.5 basically conflict with each other.

59:45
We provided comments on “demonstrates” previously and requested it be changed to “determines”

01:00:09
+1 to determines

01:00:10
That’s fine

01:00:12
Determines works.

01:01:34
@James: Good point.

01:02:00
ICANN has a vested interest in making sure it’s co-controllers aren’t breaking any laws.

01:02:07
Note that this process doesn’t foresee any ‘granting’ - per 16.5, following the notification by the CP, automated processing would halt.

01:02:33
It seems like that would be common sense, but wasn’t our experience under the previous process. Thanks.

01:03:00
maybe we should clarify that a bit?

01:03:16
(referring to James B’s comment above)

01:05:43
@MarkSV: I’d be interested to hear any elaboration on the technical/financial feasibility bit.

01:06:32
The speed of processing is less important so long as processing is halted during consideration (16.5). This was also a problem with the earlier process, where CPs were required to comply with the policy even after notifying ICANN that it was legally impermissible.

01:07:18
@MarkSV: Are you suggesting that an entity other than the CP should determine what is technically/financially feasible for it to do?!

01:07:31
I’m not sure that I understand what you’re saying.

01:07:41
@Amr, I'm about to suggest that :-)

01:07:49
Yikes!!

01:08:00
Kind of :-)

01:08:15
“Commercially Feasible”. I always think of the small Registrar that has to build & deploy a system connecting to SSAD, but they only receive 1 request a year

01:08:34
+1 James, that was the illustration we made to Brian the other day

01:09:16
ANd corporate registrars like Mark Monitor and AppDetex will need to build and maintain this, but do they really expect to receive a high volume of requests?

01:09:36
@James: Even large registrars may determine that automating disclosures may not be financially feasible. Why should a CP have to dedicate resources to automate, if it doesn’t even receive disclosure requests in a given category of use cases, or even just 1 or 2 a year?

01:10:01
@James: I think you just said what I was trying to. :-)

01:10:52
@Amr - for large registrars, the economic incentive for automation is very clear.

01:11:46
let‘s not

01:12:09
+1 James. And I would consider how to protect very small Rrs. But if a medium-sized Rr just doesn't want to do it, it seems like a big hole

01:13:54
I am re-reading for Janis' comment

01:15:36
What are some reasonable guardrails on commercial feasibility?

01:15:56
Registrars with fewer than 100 domains under management? 100,000?

01:16:14
@Brian: Adding commercial/technical feasibility to 16.4?

01:16:20
But small registrars can volunarily ask the CSG to automate it under the policy

01:16:20
@James, good explanation.

01:16:34
I think there’s something there Brian but not sure we can flush that all out right now

01:16:48
Registrars with fewer than 20k Port 43 queries per month?

01:16:55
Thanks, Matt. Maybe implementation?

01:17:05
I was going to maybe suggest that…

01:17:40
As a large retail registrar, I’m always surprised when I discuss WHOIS with small or niche registrars. “Yeah, we don’t really get any requests like that.” Same goes for how they process compliance or abuse reports. Some of this stuff just isn’t a factor for very small operators

01:21:15
+1 Brian -- I think 16.3 already limits automation to what's technically and commercially feasible and legally permissible.

01:21:18
rec 19 allows CPs to reject them across the board, but what if automation works for some/many CPs, but not all re: tech/commercial feasibility? They’re not the same thing.

01:22:13
@Amr - isn’t the right to object linked to legal effects produced which were reviewed by B&B in the memo (and no legal effects found for the use cases that are included here)?

01:24:02
Sorry folks — need to drop off early for another meeting. Ben will cover for SSAC. Thanks!

01:25:13
@Marika: I believe it was covered, but I don’t believe the intent was to deprive data subjects the opportunity to object.

01:25:38
@Brian: I appreciate the consideration.

01:26:57
so the individual would have to work through their Registrar to raise the “legally permissible” concern Chris?

01:27:07
Agree Amr's concern is covered by legally permissible

01:27:09
If it’s already covered, wouldn’t hurt to add it, then? Why does it complicate anything? :-)

01:27:53
I don’t get how everyone’s acknowledging the data subject’s right to object, but also opposing the data subject being allowed to practice its right!!

01:27:56
We are not editing here

01:28:06
As there are already so many redlines and not to confuse the discussion :-)

01:28:20
ok

01:29:56
I think there was agreement to change demonstrates to determines

01:29:59
+1

01:30:49
We don't agree to "determines"

01:31:04
We need to work on guardrails if we're going in that direction

01:31:14
@ Milton, so the exemption will be at the discretion of the Contracted Party?

01:31:56
Yeah 16.5 addresses my concerns that echo milton.

01:33:53
And 16.6 no?

01:34:48
Agreed Matt. No need to reinvent the wheel here methinks.

01:36:32
@James: +1

01:37:31
If anything, what James was describing goes against ICANN’s mission to foster competition in the industry.

01:38:20
i thought we agreed on determines

01:39:00
There was no agreement

01:39:10
I think we're getting closer

01:39:51
I think Janis is proposing that it is ‘determines’ for legal feasibility, and ‘demonstrates’ for commercial and technical feasibility.

01:40:00
I thought we agreed on determine for legal, not for tech and commercial

01:40:34
+1 Marika

01:41:34
+1 Brian working the details of the commercial feasibility is surely important

01:45:39
We can put a placeholder as the drafting may take a little bit of work?

01:50:07
Does someone really need it?

01:51:21
we will be here formhours. thanks, brian

01:51:47
+1 Brian

01:52:23
CPs cannot opt out of using EPP for processing. Why is this different?

01:53:08
They can actually @Alan…for some small registrars depending on the TLDs they support they wouldn’t have to implement EPP...

01:54:02
If "when" depends on "how", then we should care about it

01:54:06
@Matt - how is a decision / determination made in that case? Anything that could be helpful here?

01:54:10
@matt agree we need to be flexible lets leave this to implementation

01:54:34
@Volker: +1

01:56:23
@Milton: +1

01:56:40
Milton + 1

01:57:16
I’m not clear what Janis is proposing?

01:58:54
+1 James Agree we don't want a closed door

01:59:22
@Matt: +1

01:59:36
LOL.

02:01:18
And remember this is NOT opting out of the Policy…it’s opting out of the automation of disclosure…not the responsibility under the policy

02:02:16
@Matt, if the disclosure takes longer than the original decision would have been, there is no benefit of automation.

02:02:29
@Alan we are SLA’s, no?

02:02:35
it is not yet part of the dns.

02:03:01
We would then need an SLA for DISCLOSURE.

02:03:27
not another sla

02:03:36
Brian, you want to scrap only 16.4 bis?

02:04:10
so it is ok to be left in then, margie

02:04:16
Commercial software isn’t free.

02:04:27
At a cost…

02:05:02
All software development has some cost elements

02:05:24
We don't have exceptions based on commercial feasibility for Port 43, RDAP, Transfer Policy. Why here?

02:06:25
@James: +1

02:06:58
because those already preexist. this does not, this is new

02:07:14
@Volker but they were new at one time :-)

02:07:38
We have pointed this out in the past

02:08:39
port 43 existed before icann

02:08:59
Frankly, as Volker pointed out, we have already had this discussion and we need to have the ability to not automate if it is not cost effective

02:09:20
transfer policy is not something one can opt out of as it exsures domain portability

02:10:36
I thought we were talking about automated release of the data, not making the decision. Registrars may automate or not automate the disclosure.

02:11:15
I suspect most of the categories of use cases for automation will be edge cases, anyway…, which is why the financial feasibility question is an issue in the first place.

02:16:03
"Supporting documentation" that is, what information supports the claim that the automation is no longer legally permissible.

02:19:48
+1 Amr on the last comment in chat

02:19:59
And on using common sense here

02:21:13
@Eleeza: Please keep the questions coming, if you have them. No apologies needed for sure!!

02:21:28
Excellent questions, Eleeza.

02:21:37
@ Eleeza -- might these questions be handled during implementation?

02:23:41
Are we taking a break at the top of the hour?

02:23:52
I would argue that “input” allows affected stakeholders to provide a broader range of information, including “supporting documentation”?

02:25:32
+1 Brian