You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

The meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 - Small call  #1 is scheduled on Wednesday, 15 January 2020 at 13:00 UTC for 1 hour

The meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 - Small call  #1 is scheduled on Wednesday, 15 January 2020 at 22:15 UTC for 1 hour

RECORDINGS


Call #1

Audio Recording

Zoom Recording

Chat Transcript


Call #2

Audio Recording

Zoom Recording

Chat Transcript

PARTICIPATION


Attendance #call 1

Attendance call #2

Notes/ Action Items


Call #1 Small Team Call Rough Notes – 15 Jan 2020


  • It may be helpful to understand the concerns or objections with the CPH proposal, not as they contrast with the ideal of the centralized model, but with how it contrasts with the status quo. The timeline for the external feedback is not clear – it could be many months (if not longer) away. In addition to potentially losing time, advice (if ever received) could be more critical of the centralized model, so waiting for advice could be problematic.
  • Problem with CPH proposal is that it puts the burden on CPs and implies a time constraint. Unless a CP builds a semi-automated element to a system, there will be delays, and it ignores the 80/20 rule in that a large portion of the requests will be fairly simple. Propose to change the decision making to the Authorization provider, instead of the CP. In the initial case, the decision making could go to the CP, but the system and recommendations should build in the ability for some requests to go to the authorization provider.
  • The CPH proposal does not preclude the hybrid model from becoming more centralized as legal advice and experience is accumulated.
  • It would be preferable to remove the “hard coding” of contracted party decision-making and make it more flexible.
  • Concerned with previous comments of noting that no additional employees will be hired and timelines will inevitably be longer, and Compliance can’t do anything to fix this – this rhetoric is a non-starter for BC/IPC.
  • The CPH proposal is only marginally better than status quo. Status quo is unacceptable. Currently getting zero information; have to develop a model where third parties get more than zero.
  • In the year after GDPR went into effect, for a subset of clients across 15 brands, MM requested WHOIS data re: 1000 infringing domain names from registrars. Unclear why a different outcome is expected based on the hybrid model when it doesn’t look different from what is currently in place.
  • There is no benefit or distinction of the hybrid model of the status quo.
  • CPH – this is an improvement over status quo and waiting for advice is a huge risk.
  • How can IPC/BC convince their constituencies that the CPH proposal is an improvement over the status quo?
  • Each Team Member has its considerations on the table. CPs have hefty financial penalties from potential mistakes; BC/IPC have a negative experience with existing system and would like an improvement from that. Could a dynamic proposal be something that is accepted? It is not likely that 100% of the decision-making will always be at the CPH level b/c there will be many repetitive simple situations where the response could be given in an automated way.
  • Concern: if the CPH model is chosen or a centralized model b/c of volume and safety, the Team is almost guaranteeing high rejection rates. Somewhere in the middle is the only viable solution.
  • Takeaway from IPC/BC – do not find it acceptable if decision making rests with the contracted parties. If that is not correct, want to better understand a potential middle ground.
  • Mark Sv. slides: CPH proposal slides shows a front end and a back end. The front end is a ticketing system that feeds into a logging system – this is where the CPH proposal differs from status quo, but this was already included in the draft report, so represents nothing new. There is benefit to the front end. On the back end, the clearinghouse goes directly to the authoritative source. One thing that is not clear from the proposal is how the responses get organized. If using RDAP – it has to act as a response to the original request b/c not aware of a push model within RDAP. In summary, the front end gives value over the status quo. (This was already in the report, so this is not necessarily a breakthrough.) The differences are how the backend if configured so that it can be future-proofed. The concern is really about resourcing – if all CPs had GoDaddy and Verisign-like resources, it would not be as problematic.
  • The draft report does not offer sufficient detail for the EDPB to opine. The Team has the benefit of having CPH members on the Team that are thoroughly resourced but has to acknowledge the reality that not all CPs are similarly situated. This will lead to fragmented decision-making, and If there is fragmented decision-making, the risk is higher that this will not go unnoticed. Most of the decision-making is 6(1)(f), and there is the ability of the data subject to object to that processing, so the Team needs to think about how to document the processes to avoid and/or properly respond to objections. Part of the reason the CPs suggested what they suggested is b/c there is no progress on allocating responsibilities. It is important to have a detailed documentation, including pre-defined use cases – CPs could have the right to object with the appropriate rationale.
  • Would like to see a hybrid, hybrid model and proceed with two models to push forward.
  • Until the next call, James and Marc A to consider modifications to their proposal that would address some of the concerns expressed could be considered.




  • No labels