Logo

051040043 - EPDP-Phase 2A Team Call
Terri Agnew
31:48
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en**Members: reminder, when using chat, please select all panelists and attendees in order for everyone to see chat.
Berry Cobb
36:52
Link to memos: https://community.icann.org/download/attachments/155191493/ICANN EDPB 2a - Memo re. NIS2%2C dotEU and RIPE-NCC - 20210427.docx?version=1&modificationDate=1620089113000&api=v2
Berry Cobb
37:26
Proper link: https://community.icann.org/display/EOTSFGRD/EPDP+-P2A+Legal+subteam
Volker Greimann (RrSG)
37:29
Best legal memo ever!
Melina Stroungi (GAC)
45:58
One of the benefits of making legal v. natural distinction a requirement, would be that it would limit significantly the amount of access requests received and, thus, the need to conduct the balancing test every time
Hadia Elminiawi (ALAC)
47:01
@Becky sure thanks
Sarah Wyld (RrSG) (Tucows)
47:03
I'm not convinced that this reduction in access requests would be that helpful, since there is still work to be done at some point (either when the request is received or when the person type is determined) and the work may not be exactly the same kind of review but it's not nothing
Melina Stroungi (GAC)
49:17
@Sarah, I see. As currently on the one hand we have a lot of complaints of access requests been denied or left unanswered, and on the other hand also complaints from CPs that making the balancing test is difficult as it could expose them to liability, I believe that making differentiation a requirement could be a very positive step towards solving both problems
Volker Greimann (RrSG)
50:18
Melina, agreed that differentiation can be helpful, however being helpful does not require it to be mandatory
Melina Stroungi (GAC)
52:23
Thanks for confirming that it would be helpful :) Why not making something helpful a requirement? Especially since the only way to ensure that it has the maximum benefits for everyone would be precisely making it a requirement. On the contrary, leaving it voluntary you end up with disparities/or no benefits if no one decides to do it
Sarah Wyld (RrSG) (Tucows)
52:41
I don't recall complaints from CPs that making the balancing test is difficult. It's not easy, but it's our responsibility as the Controller reviewing the disclosure request
Steve Crocker (SSAC)
53:07
In my view, it’s essential that gating conditions such as the balancing test, approval of purposes, etc. have to be reduced to practice that is (a) done ahead of time, (b) is almost always predictable, (c) is inexpensive, and (d) is speedy.
Hadia Elminiawi (ALAC)
53:19
@Volker it is not enough to not desire a certain model. More important is how beneficial this desirability is. In our case differentiating between the registrant type first has many benefits.
Jan Janssen (IPC)
53:45
@ Volker how do you propose providing a workable solution to the problem referred to by Melinda without making it mandatory?
Brian King (IPC)
54:51
Thanks for trying, Milton. A for effort.
Mark Svancarek (BC)
55:20
+1 Thanks for the effort.
Sarah Wyld (RrSG) (Tucows)
55:22
Hadia, I think we've been saying that we don't agree this is that beneficial
Volker Greimann (RrSG)
55:37
If a registrar choses to disclose more, that will lead to less SSAD requests to review. There is benefit, that each registrar can weigh against the risks
Alan Woods (RySG)
56:39
Melina - your point re the gap between 'complaints' and 'difficulty of the balancing test' is unfortunately ignoring the fact and the continuous statement of the CP reps here that the request we continue to receive do not meet the basic bare minimum requirements to make it past a prima facie review. This from my own experience is despite my repeated requests for clarification that go unanswered.
Hadia Elminiawi (ALAC)
57:14
There is no good reason for not making differentiation between the registrant type mandatory. By now we all know this does not add any risk to CPs, on the contrary it reduces the liability of CPs who would like to differentiate now or in the future.
Volker Greimann (RrSG)
58:14
There are many. We have discussed them all before. Not going to re-state them again
Volker Greimann (RrSG)
58:43
@Hadia: So all our reasons are bad?
Hadia Elminiawi (ALAC)
59:31
+1 Melina just having a field in place without any mandatory requirements to actually using this field
Alan Woods (RySG)
59:41
to be clear the majority of requests I have received from a very large player sum up their request in '2 words' - two words … does not a proper request make. When I ask for a little more detail - silence - until the next request that ignores my previous queries.
Hadia Elminiawi (ALAC)
01:00:35
+1 Kieth exactly just a mandatory flag. Without any requirements to using it
Sarah Wyld (RrSG) (Tucows)
01:00:49
How could a flag be mandatory if using it is not required?
Sarah Wyld (RrSG) (Tucows)
01:02:21
I am not sure we could agree on that
Sarah Wyld (RrSG) (Tucows)
01:03:01
Setting up flags, but not then using them... so doing a bunch of technical work, for no discernible outcome and no benefit that we've yet agreed on either
Steve Crocker (SSAC)
01:04:07
@Sarah It is entirely sensible to distinguish between adding a data element to the common set of fields that are understood across the entire system vs requiring its use. These are incremental steps. First define the field. Second, define its possible values. Third, set policy whether it the registrar is required or only permitted to fill in this field. As a separate but related part of this is whether registrants are permitted to specify “unstated” or “unknown.”
Sarah Wyld (RrSG) (Tucows)
01:04:29
Step 0 is to agree on the problem being solved and the method of solving it, and we haven't gotten there
Brian King (IPC)
01:04:36
+1 Steve
Stephanie Perrin (NCSG)
01:04:46
+1000 Sarah
Hadia Elminiawi (ALAC)
01:04:49
@Sarah this will allow CPs who would like to differentiate in the future to do this in a consistent manner. This certainly could be beneficial and for sure has no downsides. Based on Phase 2, the CPs are going to make changes to the RDDS and thus this is the time where such a field could be added.
Sarah Wyld (RrSG) (Tucows)
01:04:59
CPs who want to differentiate are welcome to do so
Stephanie Perrin (NCSG)
01:05:16
How they do so is their business, is it not?
Owen Smigelski (RrSG)
01:05:38
@Hadia- nothing in Phase 2 requires changes to RDDS by contracted parties
Milton Mueller (NCSG)
01:05:47
wave your flag
Owen Smigelski (RrSG)
01:05:49
I agree with Sarah’s comments here in chat
Hadia Elminiawi (ALAC)
01:07:09
@Sarah please explain why is adding a flag a problem? this will allow for the fields would be consistent across registrars.
Sarah Wyld (RrSG) (Tucows)
01:07:19
Hadia I sent an email about it a few weeks ago and would refer back to that
Brian King (IPC)
01:08:12
To be clear, practically speaking, registrars will have to develop a flag in their systems in order to comply with EPDP Phase 2 anyway.
Hadia Elminiawi (ALAC)
01:08:13
*for the fields to be consistent across registrars
Sarah Wyld (RrSG) (Tucows)
01:08:58
Sorry, maybe the email I am thinking of was sent to a different list. But we did speak in detail about why flags are not a solution to everything, a few weeks ago
Margie Milam (BC)
01:09:00
+1 Steve
Hadia Elminiawi (ALAC)
01:09:12
+1 Steve
Volker Greimann (RrSG)
01:10:24
If we may find something later, let’s implement the flag then
Volker Greimann (RrSG)
01:10:41
Maybe we could implement a flag symbol in the country field ;-)
Milton Mueller (NCSG)
01:10:46
so migration to mandatory, Alan? This is one reason why NCSG won’t support flag
Margie Milam (BC)
01:11:14
+1 Alan G
Volker Greimann (RrSG)
01:11:41
How about this: Recommend a flag, define the format it should take if implemented and make it voluntary
Alan Greenberg (ALAC)
01:12:16
@Milton, "migration to mandatory"? I never said anything about that.
Melina Stroungi (GAC)
01:12:48
taking action now rather than deferring it to later is at the very core of choosing to self regulate ;)
Hadia Elminiawi (ALAC)
01:15:08
This is the time to self-regulate, to just ignore everything we have in this regard is a big mistake.
Melina Stroungi (GAC)
01:15:13
or we could agree to an implementation deadline which could feel comfortable for you
Brian King (IPC)
01:15:44
+1 Melina, that's reasonable and is often a reasonable way to compromise.
Volker Greimann (RrSG)
01:16:21
I was not saying that. Define a voluntary field: Yes
Volker Greimann (RrSG)
01:16:27
There must be a flag: No
Brian King (IPC)
01:16:47
There is definitely an opportunity for consensus here.
Berry Cobb
01:17:17
Staff will take the action to include today's deliberation to include in the next verison of the write up for groups to react to and evolve.
Keith Drazek (Chair) (Verisign)
01:17:38
Thanks Berry
Volker Greimann (RrSG)
01:20:43
Maybe there should be an RFC for the field?
Volker Greimann (RrSG)
01:21:05
So instead of policy, we use standardisation
Hadia Elminiawi (ALAC)
01:21:08
@Volker really?
Sarah Wyld (RrSG) (Tucows)
01:21:27
Treating newly-updated registrations the same way we'd treat a brand new domain when collecting data (as Brian just said) sounds reasonable to me
Hadia Elminiawi (ALAC)
01:21:36
@Volker do we have an RFC for every RDDS field?
Volker Greimann (RrSG)
01:22:14
Only for this one.
Alan Greenberg (ALAC)
01:22:37
ALl I am asking is that there be a new line in the tables of RDDS fields in Rec # 5-10 of the Phase 1 report.
Hadia Elminiawi (ALAC)
01:23:01
@Stephanie we agree registrants will need to self identify
Alan Greenberg (ALAC)
01:23:07
Just as with Tech contacts, it is optional for a Rr to use.
Steve Crocker (SSAC)
01:23:28
@Volker - As it turns out, the documentation of existing fields is fairly ragged across the entire system. I don’t believe there is an RFC that gives complete documentation of the existing fields. Some of the details are buried in the EPP material. But there really should be an organized list of defined fields. In the work we’ve doing, we use the term “data dictionary” to refer to this concept.
Sarah Wyld (RrSG) (Tucows)
01:23:30
Right, but I think adding a new line in the RDDS fields requires RFC updates
Sarah Wyld (RrSG) (Tucows)
01:23:42
(oh, ok, reading Steve's comment now)
Alan Greenberg (ALAC)
01:24:56
@Sarah, we made many changes to RDS fields in Phase 1 without any RFC.
Sarah Wyld (RrSG) (Tucows)
01:25:08
AlanG, that is true.
Steve Crocker (SSAC)
01:25:09
It might be more appropriate to use the protocol registry system to list the fields that are defined. An RFC would then point to the registry, and the registry could be augmented without issuing an RFC each time.
Steve Crocker (SSAC)
01:26:35
To be clear, I am referring the registries that are part of the IANA protocol parameter registry system, not TLDs.
Hadia Elminiawi (ALAC)
01:26:52
+1 Alan
Milton Mueller (NCSG)
01:27:34
LOL
Milton Mueller (NCSG)
01:27:41
careful, careful
Brian King (IPC)
01:28:22
I need to drop at the top of the hour. Thanks all.
Tara Whalen (SSAC)
01:28:25
I need to drop from the call now, handing off to Steve C. Thanks, all!
Milton Mueller (NCSG)
01:32:32
my objection is not to the subcontracting but has always been to the Rr making the decision for the registrant
Stephanie Perrin (NCSG)
01:32:51
Thanks Alan, then you agree it should be dropped.
Hadia Elminiawi (ALAC)
01:33:13
If we remove this scenario, the CP can still subcontract others if needed
Stephanie Perrin (NCSG)
01:33:41
Precisely what I put int the comment Thomas, if I recall correctly.
Volker Greimann (RrSG)
01:34:34
No need to state the obvious. Do we need this language?
Stephanie Perrin (NCSG)
01:34:40
This mention of a subcontractor in this policy leads one to assume that this is function of the SSAD, which automatically brings in ICANN
Mark Svancarek (BC)
01:35:51
#snark
Hadia Elminiawi (ALAC)
01:35:58
recipe please
Milton Mueller (NCSG)
01:36:03
no tomatos,they cause cancer
Sarah Wyld (RrSG) (Tucows)
01:36:10
noodles or crackers?
Volker Greimann (RrSG)
01:36:41
Should we recommend Tomato Soup over other soups?
Milton Mueller (NCSG)
01:36:52
all the #3 language? FAvor
Melina Stroungi (GAC)
01:39:41
agree it could help
Sarah Wyld (RrSG) (Tucows)
01:40:05
Could we see where the 15 days goes in the text?
Berry Cobb
01:41:53
@Sarah it will be added in the next iteration for feedback.
Stephanie Perrin (NCSG)
01:43:03
NCSG would like to remove scenario 3 entirely
Milton Mueller (NCSG)
01:43:03
We do need to have it, we have been calling for it for three weeks
Stephanie Perrin (NCSG)
01:45:15
We actually would like to drop the inclusion of guidance in this policy. The Registrars can and do provide guidance for their members all the time.
Keith Drazek (Chair) (Verisign)
01:45:37
Noted Stephanie regarding NCSG views.
Stephanie Perrin (NCSG)
01:45:39
There are too many unknowns, complications, and expenses in here to include voluntary guidance in the policy
Milton Mueller (NCSG)
01:47:31
Yes +1 Alan
Milton Mueller (NCSG)
01:47:43
or they could eat tomato soup
Volker Greimann (RrSG)
01:48:02
No objection to removal, as suggested by Alan
Stephanie Perrin (NCSG)
01:50:01
This is one of the reasons why I have been proposing for years that companies be able to authenticate themselves. There are plenty of benefits, including customer trust. However, the wide disparity in entity size makes advice difficult to give. This is why we favour removing it from this policy and let the registrars give it themselves.
Sarah Wyld (RrSG) (Tucows)
01:50:35
Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in and of itself).The EPDP Team has identified three different high-level scenarios for how differentiation could occur based on who is responsible and the timing of such differentiation. It should be noted that other approaches and/or a combination of these may be possible.
Sarah Wyld (RrSG) (Tucows)
01:50:39
how about that? :)
Sarah Wyld (RrSG) (Tucows)
01:51:00
If Alan wants to propose additional text there I'm certainly open to it
Alan Greenberg (ALAC)
01:52:02
At this point, it is NOT policy.
Melina Stroungi (GAC)
01:52:35
fine to include a text as preamble indicating that these scenarios are examples
Alan Greenberg (ALAC)
01:53:11
We have been told that policy is a possible outcome of a PDP. Sadly (to me), we have not chosen that path.
Stephanie Perrin (NCSG)
01:53:40
Not just the scenarios, the guidance itself. Otherwise, this guidance will be relied on in Court and in future accuracy discussions, if we get there.
Sarah Wyld (RrSG) (Tucows)
01:53:41
that is a copy paste from the doc, it is not my draft
Sarah Wyld (RrSG) (Tucows)
01:53:51
I was pointing out that we already have the kind of caveat people are requesting
Keith Drazek (Chair) (Verisign)
01:54:04
Thanks Sarah, noted.
Berry Cobb
01:54:56
AI Log with links to homework: https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0
Terri Agnew
01:56:14
The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Tuesday, 11 May 2021 at 14:00 UTC for 90 minutes.
Berry Cobb
01:57:32
All good, thanks
Caitlin Tubergen
01:57:33
Nothing from me.
Hadia Elminiawi (ALAC)
01:57:49
Thank you all bye