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.

who is „Netchoice“?

Steve DB?

@Volker, I just renamed.

Yes, Steve DelBianco

thx

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

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

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

becaus

because we compromised?

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

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

Not even. A paragraph - a section

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.

That’s not our understanding at all

Very frustrating

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

Yes please

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

@Volker: +1

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

Demonstrates to who?

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

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

+1 to determines

That’s fine

Determines works.

@James: Good point.

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

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

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

maybe we should clarify that a bit?

(referring to James B’s comment above)

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

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.

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

I’m not sure that I understand what you’re saying.

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

Yikes!!

Kind of :-)

“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

+1 James, that was the illustration we made to Brian the other day

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?

@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?

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

@Amr - for large registrars, the economic incentive for automation is very clear.

let‘s not

+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

I am re-reading for Janis' comment

What are some reasonable guardrails on commercial feasibility?

Registrars with fewer than 100 domains under management? 100,000?

@Brian: Adding commercial/technical feasibility to 16.4?

But small registrars can volunarily ask the CSG to automate it under the policy

@James, good explanation.

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

Registrars with fewer than 20k Port 43 queries per month?

Thanks, Matt. Maybe implementation?

I was going to maybe suggest that…

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

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

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.

@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)?

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

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

@Brian: I appreciate the consideration.

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

Agree Amr's concern is covered by legally permissible

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

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!!

We are not editing here

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

ok

I think there was agreement to change demonstrates to determines

+1

We don't agree to "determines"

We need to work on guardrails if we're going in that direction

@ Milton, so the exemption will be at the discretion of the Contracted Party?

Yeah 16.5 addresses my concerns that echo milton.

And 16.6 no?

Agreed Matt. No need to reinvent the wheel here methinks.

@James: +1

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

i thought we agreed on determines

There was no agreement

I think we're getting closer

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

I thought we agreed on determine for legal, not for tech and commercial

+1 Marika

+1 Brian working the details of the commercial feasibility is surely important

We can put a placeholder as the drafting may take a little bit of work?

Does someone really need it?

we will be here formhours. thanks, brian

+1 Brian

CPs cannot opt out of using EPP for processing. Why is this different?

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

If "when" depends on "how", then we should care about it

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

@matt agree we need to be flexible lets leave this to implementation

@Volker: +1

@Milton: +1

Milton + 1

I’m not clear what Janis is proposing?

+1 James Agree we don't want a closed door

@Matt: +1

LOL.

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

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

@Alan we are SLA’s, no?

it is not yet part of the dns.

We would then need an SLA for DISCLOSURE.

not another sla

Brian, you want to scrap only 16.4 bis?

so it is ok to be left in then, margie

Commercial software isn’t free.

At a cost…

All software development has some cost elements

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

@James: +1

because those already preexist. this does not, this is new

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

We have pointed this out in the past

port 43 existed before icann

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

transfer policy is not something one can opt out of as it exsures domain portability

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

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.

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

+1 Amr on the last comment in chat

And on using common sense here

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

Excellent questions, Eleeza.

@ Eleeza -- might these questions be handled during implementation?

Are we taking a break at the top of the hour?

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

+1 Brian