[Gnso-epdp-team] Notes and action items - EPDP Team Meeting #44

[Caitlin Tubergen]

Dear All,

 

Please find the notes and action items from today’s EPDP Team call.

 

Best regards,

 

Marika, Berry, and Caitlin

 

EPDP Team Meeting #43

Wednesday, 6 February 2019

Notes and Action Items

 

 

High-level Notes/Action
EPDP Team to review the table of outstanding items, which was circulated to the list. yesterday. Please note the Support and Leadership teams’ proposed path forward and please flag the options you cannot accept.
Support Team to update Recommendations 10, 11, and 12 (Email, Data Retention and Reasonable Access, respectively) to account for today’s discussion and circulate the updated text to the list.
Support Team to circulate updated Final Report draft tomorrow, Friday, 8 February. 
 

Notes  

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ .

 

Proposed Agenda:

 

1.  Roll Call & SOI Updates
Attendance will be taken from Adobe Connect
Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes.
Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.
2. Welcome and Updates from EPDP Team Chair (5 minutes)

                a.   Review of outstanding action items

                b.   Other updates, if applicable

 
Please review the table sent yesterday, which outlines outstanding issues raised by team members and includes proposed paths forward, suggested by the leadership team
 re: outstanding issues raised and the proposed path forward from the leadership team
The Support Team will  send an updated version of the Final Report tomorrow
 

3.  Implementation Bridge

 
Per last week’s action item, CPH to present language/approach for implementation bridge discussion
a.   CPH to present updated language proposal

 

CPH Proposed Language: The EPDP Team recommends that the effective date of the gTLD Registration Data Policy shall be [DATE]. All gTLD Registry Operators and ICANN-accredited registrars will be required to comply with the gTLD Registration Data Policy as of that date. The EPDP Team recommends that until [DATE], registries and registrars are required EITHER to comply with this gTLD Registration Data Policy OR continue to implement measures consistent with the Temporary Specification (as adopted by the ICANN Board on 17 May 2018, and expired on 25 May 2019). Registries and registrars who continue to implement measures compliant with the expired Temporary Specification will not be subject to Compliance inquiry specifically related to those measures.

 
When would the date be filled in?
The date could be up for discussion. The initial placeholder was January 1, 2020. The thinking behind this proposal is that it lightweight and accounts for companies who are able to comply sooner and those who may need extra time. It also allows Compliance to have an enforcement mechanism.
Some contracted parties were concerned with this language, so this represents a compromise.
The proposed language looks good, though it will be important to figure out the date. A date may also need to be inserted into the last sentence.
How would a third party know which regime the contracted party chooses to operate under?
It may be helpful to have a defined term for the date, such as consensus policy date. Agree that there needs to be some signal as to which regime the contracted party is operating under.
Need more clarification on the last sentence- what does "will not be subject to compliance inquiry" mean?
In the last sentence, suggest changing inquiry to action.
The group can put a date on the table - there is likely not time for an IRT. January 1, 2020 was the first idea thrown out. Re: the term compliance inquiry, that should be changed - perhaps compliance sanction could be considered. Should there be a date in the last sentence? Yes, that is OK. Re: which regime a CP is operating under? That will be more difficult.
Perhaps the date should not be January 1, as it's difficult to finalize changes over a holiday.
CPs could let ICANN know which regime they're operating under, and ICANN could publish this.
The Team could put in a target date. The IRT does not begin until the Board adopts the recommendations.
The reason a target date is proposed is b/c you cannot fix yourself to a certain date in the event the implementation is ready. The effective date can only be confirmed once implementation is completed.
Action: contracted parties to consider a target date.
Could the group form a mirrored group similar to the IRT that could start sooner than the IRT?
Disagree with the term target date.
b.   Discuss proposal

                c.   Confirmation of agreement reached or next steps to come to agreement

 

4. Recommendation #12 - Reasonable Access (30 minutes)

                a.            Review revised proposal

                b.            Discuss revised proposal

 
Having an auditable system is necessary; it is not about penalizing the contracted parties. The objective is to allow a trusted system to exist.
This looks like the focus has been shifted to the request itself rather than the process for dealing with the request.
The onus and burden is flipped - the onus is on the requestor to make a reasonable request. The trusted system we are working with is the GDPR.
Thomas' added sentence may be too restrictive. What about out of jx requests?
The reason the clarification was inserted was not to deter law enforcement. 6(1)(f) allows for the disclosure of data if you perform the balancing test. 6(1)(f) cannot be used by public authorities in performing their core functions. It's not appropriate for us to establish criteria for law enforcement.
Perhaps this sentence could be preserved but not included as the "headline".
The first bullet re: two business days to determine if something is reasonable and lawful may be too short. Perhaps it can be two business days to acknowledge receipt.
This would stay in place unless replaced by another policy.
This is not intended to be the last word on access to data. This is a placeholder to sort out procedural responsibility for non-law enforcement actors.
Thomas' language should be included at the top.
The wording changes include: Amr's comments about 2-day response period and that this is acknowledgement - wording in chat has been accepted. Response time for acknowledging receipt of disclosure requests" seems fine to me. This would cover both disclosure requests that are reasonable/lawful, and those that aren't. I suspect it would be too soon to determine which bucket the disclosure requests falls into within 2 days after it's submitted.
Ashley's wording seems to have gained acceptance.
c.             Confirmation of agreement reached or next steps to come to agreement

 

5. Recommendation #10 – Email Communication

                a.   Review revised proposal

                b.   Discuss revised proposal

Action: support team to specify RAA requirement to address SSAC's concern in the text.
In reference to the "must not identify" would provide that registrars could provide an option that redacted information be displayed. If possible or if practical, bounced messages should be included in the log. Registrars may log bounced emails, but they do not act on it.
Add something like 'unless as per recommendation X, the registrant has provided consent for the publication of the email address'?
Bounced emails should be separated from the webform.
Even though the RAA requires the registrar to act, there is still a gap that the requestor does not know that the email is bounced. What kinds of action are the registrars are concerned with and address them? There may be a decent volume of requests depending on requests. Would not want to leave the impression that a large number of requests could be sent as long as the requests are valid.
The logic being proposed is not thinking at scale. Registrars can be held to the requirements that they transmit a notification and keep records that the transmission was sent. Requiring a registrar to ensure that the transmission is received, read and acted upon is not practical.
Prevent abuse - any process that allows registrars to block an IP address of the source if someone is abusing the system.
It may be helpful to give readers an example of the abuse we are trying to address.
Registrars cannot be expected to follow up on ever bounced message, but at the very least, they should be included in the log file.
Concerned with the last sentence of Note 2.
This follows the agreement reached in principle in Toronto - the Council may look into this email issue. Is it policy work, is it something else? It's an area where several groups have noted concerns, so this is designed to allow the Council to consider further.
Request to separate the web form and the pseudonymized email address.
The GNSO could consider working with technical arms to further address this issue. The note could be reworded to account for this.
Potentially three things to add to the notes on the rec: (1) note SSAC's questions and how that is addressed; (2) a note that reasonable is meant to take reasonable steps to combat specific abuses - it's not a reason for ignoring legitimate requests; (3)  unless as per recommendation X, the registrant has provided consent for the publication of the email address'
c.   Confirmation of agreement reached or next steps to come to agreement

 

6. Recommendation #11 – Data Retention

                a.    Review revised proposal

                b.            Discuss revised proposal
ICANN Org sent a message with other known processes requiring retention
The TDRP is not the longest-specified retention period, but rather well-justified period.
It is for the controller to set the retention period, not someone else.
A lot of work needs to be done with respect to what ICANN can claim.
The term - as a matter of urgency should be added to paragraph 1.
Is this recommendation intended to override the RAA data retention spec?
The answer to does this replace the data retention specification? Yes.
A registrar will not turn around and delete data, but the retention period in the contract does not have a reason – that is why the team underwent the analysis and noted the TDRP.
Troubling that we are not clear on this at this point in time. With a good data map, you can determine who is in control of what.
c.             Confirmation of agreement reached or next steps to come to agreement

 

7. Review of additional topics raised from table (if time allows)

 

8. Wrap and confirm next meeting to be scheduled for Monday, 11 February 2019 at 14.00 UTC (5 minutes)

                a.            Confirm action items

                b.            Confirm questions for ICANN Org, if any

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190207/3aa41c85/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190207/3aa41c85/smime-0001.p7s>