February 2019 - Gnso-epdp-team

Re: [Gnso-epdp-team] Proposed path for additional topics flagged
by Marika Konings Feb. 8, 2019

Feb. 8, 2019

Please use the attached version which has the numbering included as referenced below. Apologies for the inconvenience, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Wednesday, February 6, 2019 at 11:22 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed path for additional topics flagged Dear EPDP Team, The leadership team has reviewed the additional topics that were put forward for EPDP Team consideration by the deadline and has suggested a path forward in the attached document. Please do have a look to make sure that you are comfortable with the proposed path forward and confirm that it aligns with the EPDP Team discussions to date. We would like to especially draw your attention item 3 (optional tech contact), item 6 (redaction) and item 11 (purpose 1). If your group is not comfortable with the proposed path forward for any of the topics in the table, please flag this as soon as possible, preferably prior to tomorrow’s meeting so it can be added to the agenda for tomorrow’s meeting, but no later than Thursday 7 February COB. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

3 2

REMINDER: Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Monday, 11 February 2019 at 14:00 UTC
by Terri Agnew Feb. 8, 2019

Feb. 8, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u Agenda wiki page: https://community.icann.org/x/TJ0WBg Thank you. Kind Regards, Andrea

1 0

EPDP Consensus Call #2
by Kurt Pritz Feb. 8, 2019

Feb. 8, 2019

Hi Everyone: I am trying to keep up with the comments on the list so am gaining an appreciation for the position of you members of the team. Thanks for your involvement and the tone in your emails - obviously trying to find a path to finishing each of these recommendations. Nonetheless, I am delivering the second set of Recommendations in this consensus call process. Please note that, given the recent discussion on the email list, I have moved three of the Recommendations out of “Bundle 2,” which includes those Recommendations where discussion is considered completed. These Recommendations are now in Bundle 3 and in blue font. The three sections are: The Purposes for Processing Registration Data: Purpose 1 - Establish the rights of a Registered Name Holder Purpose 2 - Maintaining SSR through enabling of lawful access Purpose 3 - Enable communication with RNH Purpose 4 - Safeguarding RNH's Registration Data Purpose 5 - Handling Contractual Compliance Purpose 6 - Resolution of DRPs Purpose 7 - gTLD registration policy eligibility criteria Recommendations considered completed in our earlier discussions: Recommendation #2 - Commitment to consider a system for Standardized Access to non-public Registration Data Recommendation #3 - Requirements related to accuracy Recommendation #15 - URS / UDRP Recommendation #16 - Instructions for RPM PDP WG Recommendation #18 - Data processing agreements with dispute resolution providers (incl. Question #4) Recommendation #19 - Transfer Policy Recommendation #20 - Input to Transfer Policy review (incl. Question #5) Recommendation #21 - Data processing agreements with non-Contracted Party entities involved in registration data processing Recommendation #6 - Escrow Providers New – Consent to publish additional information Recommendations in the process of being completed or where there is disagreement: Recommendation #9 - Organization field Recommendation #NEW - City Field Recommendation #10 - Email communication Recommendation #14 - Responsible parties Recommendation #4 - Data elements to be collected by Registrars (incl. Question #2) Recommendation #5 - Data elements to be transferred from Registrars to Registries Recommendation #New - Geographic Basis Recommendation #New - Natural vs. legal Recommendation #12 - Reasonable access Recommendation #NEW - Implementation Transition Period Recommendation #11 - Data retention Recommendation #22 - Impact on other policies Recommendation #NEW - Additional Purposes Recommendation #8 - Redaction Recommendation #13 - Controller Agreement Recommendation #7 - Contractual Compliance On this second set, please revert to me by the end of Thursday if you disagree with my assessment and if you will provide a statement for the final report. Remember that you can support a consensus position and still provide a statement. If we can in someway extend these deadlines (and we are working to do that), I will let you know. Thank you for your attention on this and all else. Sincerely, Kurt

5 5

Re: [Gnso-epdp-team] [Ext] Re: FW: Response from ICANN Compliance re. registrations under the 2009 RAA
by Alan Greenberg Feb. 7, 2019

Feb. 7, 2019

No it does not. "Any contact information" might be Tech contact which is not a contact for the RNH itself. And it does not require there to be both telephone and e-mail. And that is the current minimum contact requirement. My version says that and also gives contracted parties full flexibility in implementing. Immediately following this meeting, I will be driving all day and will be out of contact. Alan At 07/02/2019 09:25 AM, Ayden Férdeline wrote: Okay, thanks Alan. "Published" was the wrong word for me to use then in my explanation, because you are right that we are talking about collection as well, but I still think the language that I proposed addresses both of our concerns? Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 7, 2019 9:13 AM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: At 07/02/2019 08:41 AM, Ayden FÃ©rdeline wrote: Hi Alan G., I hope to find a compromise here so that we can move forward, but I find your language to be too prescriptive. I don't understand why we'd call out "voice telephone and email contact information"? I used those terms because they are the ones that are used in the RAA and my understanding was that being specific as to which fields we are talking about. Surely if these are fields that are mandatory for a registrant to provide, in asking for full contact information (of mandatory fields), they would be covered? No, that is the entire point. In the 2009 RAA, there were not considered mandatory. That is why they may be missing as stated in the opening clause. I also have concerns with the sentence, "Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." I believe this sentence is redundant. It is not redundant and not prescriptive. It is telling registrars (and registrants) that they have complete flexibility on how they treat these fileds once our policy is active. As it stands, we have another recommendation that allows a RNH to request that additional data elements be published. This has nothing to do with publishing. It is about whether the fields exist at all and whether they need to be collected. And it is about protecting registrant in the case of a Rr/Ry failure. Alan May I suggest the following language: Redline: Recognizing that in the case of some existing registrations, there may be an Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains contact information. Best wishes, Ayden â€�â��â��â��â��â�144;â€�â�� Original Message â��â��#144;â��â��â��â��â�� On Wednesday, February 6, 2019 10:59 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Hi Ayden, The issue is not collecting and maintaining. It would be foolish for registrars to have to collect Admin data post-EDPD-policy implementation if the intent is to get rid of the field. All of those registrations where they might collect Admin data, we know that the Registrant contact details are mandatory (since they would be subject to 2013 rules). The issue is we cannot eliminate the field from the database structure (and eliminate disclosing it when applicable) until we make sure there are no empty registrant contact fields. Moreover, as I pointed out in the my previous message, a registration might include Technical contact info but that is not sufficient to replace Registrant/Admin. Here is something that will work. "Recognizing that in the case of some existing registrations, there may be Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." This would ensure that we do not eliminate the Admin fields until we can ensure that every registration (and particularly every registration in the escrow files) has SOME contact info for someone responsible for the registration. That protects the registrant, but does not required Registrars to keep collecting data that is being phased out. The list of fields to be collected would have to note this recommendation instead of just omitting the Admin fields. Alan At 06/02/2019 05:57 PM, Ayden FÃƒÂ©rdeline wrote: Hi Alan, I have tried to strike a balance between the text I shared earlier and the comments you have raised here. Here is what I have come up with: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain contact information. Can you live with this? I have removed the reference to "some contact", which you found vague, and "name", because you noted this was unnecessary given the RAA. However I have still deleted the last sentence, because I do think it is redundant. Best wishes, Ayden Ã¢��Ã¢��44;Ã¢��Ã¢��Ã¢��Ã¢��Ã¢�4;Ã¢€� Original Message Ã¢��Ã¢�4;Ã¢â�â‚¬�Ã¢��Ã¢��Ã¢��Ã¢�Ã¢�Ã¢â�¬� On Wednesday, y, February 6, 2019 5:27 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Now that I have posting rights again: Two comments on "... will contain the name and contact information of some contact" - It is not really necessary to mention "name" since the 2009 RAA did require a Name field for the Registrant. - "some contact" is too wide, since we are still requiring (optionally) a technical contact which may not be the entity responsible for the registration (for instance it my be the hosting provider). Since we are also eliminating the Billing fields, the Registrant is the only remaining non-technical contact, so replacing the phrase with: "... will contain full Registrant Contact information" That also eliminates the need for the e.g. Regarding Ayden's recommendation to eliminate the final sentence, I do not agree. We need to make it clear that ensuring the Registrant contact information being present is a gating requirement to elimination of the Admin fields. We could in fact stop collection admin contact details before that, because for all new or changing registrations the 2013 rules apply which ensures Registrant data. Alan At 06/02/2019 06:58 AM, Ayden FÃƒÆ’Ã�Â©rdeline wrote: Thanks, Marika. I have some suggested edits, which are stylistic and not substantive: Redline: Recognizing that in the cases of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to in eliminating the collection and maintenance of the current Aadministrative Ccontact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact., e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact. Best wishes, Ayden FÃƒÆ’Ã�Â©rdeline > ÃƒÂ¢��ÃƒÂ¢��ÃƒÂ¢�¢€�ÃƒÂ¢��¬�ÃƒÂ¢Ã¢144;ÃƒÂ¢Ã�¢�Â¬�ÃƒÂ¢��ÃƒÂ¢�� Ori; Ori; Original Message ÃƒÂ¢�ÃƒÂ¢��ÃƒÂ¢�ÃƒÂ¢�ÃƒÂ¢��ÃƒÂ¢��Ã¢�Â¢‚Â¬�ÃƒÂ¢�� On Tuesday, Febrruary 5, 2019 66:18 PM, Marika Konings <marika.konings(a)icann.org> wrote: In line with the comments made, would the following work for inclusion in the Final Report: New Recommendation: Recognizing that in the cases of some registrations, there may be an Admin Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, in eliminating the collection and maintenance of the administrative contact, the Registrar MUST ensure that each registration will contain the name and contact information of some contact, e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. If you have any concerns about this proposed language, please share this with the mailing list by Wednesday 6 February COB. Best regards, Caitlin, Berry and Marika From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, February 4, 2019 at 18:20 To: Kurt Pritz <kurt(a)kjpritz.com> Cc: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] FW: Response from ICANN Compliance re. registrations under the 2009 RAA Kurt, that would be fine. But that is not "elimination of the field". The registrar "ensuring" must happen before the field disappears. We have an escrow program to protect registrants against failures in registrars and registries. The escrow data going forward must always include contact info. I am just about to name an alternate for tomorrow and will lose posting privileges to this list. Alan At 04/02/2019 07:07 PM, Kurt Pritz wrote: Thanks for this Alan: Might another approach be to write into the policy something to the effect that, ÃƒÆ’Ã�Â¢��Recognizing thatat iat in thehe cases of s some registrations there is an ÃƒÆ’Ã�Â¢��Adminin ContactÃƒÆ’Ã�Â¢�but n€but no Registered Name ame Holder or any otherr contact, it is required that, in the eliminating the collection and maintenance of the administrative contact, the registrar will ensure that each registration will contain the name and contact information of some contact, e.g., the registered name holder.ÃƒÆ’Ã�Â¢�� Something like that to let eaach registrar manage its own situation and also to give compliance a way to monitor registrations to ensure that there is contact information. Best regards, Kurt On Feb 4, 2019, at 3:58 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Another alternative is to say that the Admin contacts are not to be collected for new, changed or transferred registrations (which are all subject to the 2013 RAA requirement for Registrant contact data) and that the fields will be eliminated once all registrars confirm that all of the registrations under their sponsorship have Registrant contact information. Alan At 04/02/2019 05:14 PM, Alan Greenberg wrote: I do not believe that we can eliminate the Admin contact information (as currently recommended) without a concrete idea of how many registrations might be left without contact information and just a note that implementation should investigate the potential impact. If that investigation (if it is even possible given the data that ICANN possesses) we to show that there are a substantive number of such registrations, what could they do? We know that registrars have resisted the requirement to take corrective action on registration (which is why the validation/verification requirements in the 2013 RAA only apply when there are changes). If we eliminate Admin fields, we must provide for ensuring that all registrations have contact information within a relatively short period of time. The easy fix given the timeline is to not eliminate the Admin fields. Alan At 04/02/2019 08:19 AM, Marika Konings wrote: Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan GreenbergÃƒÆ’Ã�â��Ãƒ�Ã�Â¢Ã‚Â¢��s Questistion: br> < The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: ÃƒÆ’Ã�â��Ãƒ�Ã�Â¢��‚Â¢€œAs parart of the implplplplementation, consideration needs toto be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)ÃƒÆ’Ã�â��Ã™Ãƒ�Ã�Â¢��? ; > br> > Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation fforr Asssiggned Namees and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

6 7

Notes and action items - EPDP Team Meeting #44
by Caitlin Tubergen Feb. 7, 2019

Feb. 7, 2019

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

1 0

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Thursday, 07 February 2019
by Andrea Glandon Feb. 7, 2019

Feb. 7, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 07 February 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/R50WBg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-07feb19… AC Recording: https://participate.icann.org/p9kjnzwh3uj/ <https://participate.icann.org/p9kjnzwh3uj/?OWASP_CSRFTOKEN=52ea284f72e587ea…>** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Monday, 11 February 2019 at 14:00 UTC
by Andrea Glandon Feb. 7, 2019

Feb. 7, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/TJ0WBg Thank you. Kind Regards, Andrea

1 0

Notes and action items - EPDP Team Meeting #43
by Marika Konings Feb. 7, 2019

Feb. 7, 2019

Dear EPDP Team, Apologies for the delay, but please find attached the notes and action items from yesterday’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika EPDP Team Meeting #43 Wednesday, 6 February 2019 Notes and Action Items High-level Notes/Actions: Action item #1: Staff support team to circulate the second set of legal questions that have been sent to Bird & Bird for EPDP Team information. (COMPLETED) Action item #2: ICANN Org to respond to questions posed by RySG in relation to Controller Agreements (recommendation #13) and Contractual Compliance (Recommendation #7), as soon as possible. (COMPLETED) Action item #3: Registrar team encouraged to review BC input on Recommendation 9 - Org field - and provide feedback on the mailing list. Action item #4: EPDP Team to further review / consider Data Elements to be Transferred from Registrars to Registries (Rec 5) and put forward proposed language for the Final Report, factoring in today's discussion (that could also be in relation to Rec #22, Impact on Other Policies). Action item #5: Staff Support Team to update Recommendation #5 (Data Elements to be Transferred from Registrars to Registries) in line with edits suggested by Ayden during the meeting. (COMPLETED) Action item #6: Leadership to work with legal committee on possible question in relation to Thick WHOIS. Margie to provide initial question draft for Legal Team review. Action item #7: In response to ICANN-raised issues, staff support team to circulate proposed language to address process for amendments to Registry - Registrar Agreements. (COMPLETED) Action item #8: In response to ICANN-raised issues, RySG reps to work with ICANN Org on proposed path forward in relation to bulk registration data access to ICANN. Action item #9: EPDP Team to continue discussion on the mailing list in relation to recommendation #12 (Reasonable Access) in view of coming to agreement by tomorrow's meeting. Questions for ICANN Org from the EPDP Team: None Notes & Action items 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 * Target to end this meeting in 1 hour and 15 minutes to avoid conflicts with other meetings * Set of legal questions have been sent to Bird & Bird, addressing city field / redaction, meaning of accuracy with regards to GDPR, geographic implications / stable establishments. Action item #1: Staff support team to circulate the second set of legal questions that have been sent to Bird & Bird for EPDP Team information. * Encourage continued mailing list deliberations. See input / questions in relation to recommendation #13 - ICANN Org requested to respond to questions posed by RySG as well as rec #7 (compliance) questions from James. Note also issues flagged in relation to Rec #9 - Org field. Action item #2: ICANN Org to respond to questions posed by RySG in relation to Controller Agreements (recommendation #13) and Contractual Compliance (Recommendation #7), as soon as possible. Action item #3: Registrar team encouraged to review BC input on Recommendation 9 - Org field - and provide feedback on the mailing list. 3. Recommendation #5 – Transmission of Registration data from Registrar to Registry (30 minutes) a. RySG to present updated language proposal b. Discuss proposal c. Confirmation of agreement reached or next steps to come to agreement * See updated language circulated by RySG - two-pronged approach taken. Concept of the workbooks, although vital to provide the context, are specifically as an annex as work done to come to a conclusion, not the policy recommendation itself. Bullet two, in relation to purpose 1B - depending on the individual registry and controllership, they might not need the transfer of registrant data to fulfil their purposes. As such, proposed rewritten bullet 2 - explaining this concept of "mean data set" - each purpose has its own minimum data set. Collection can be unique, but it is for each one of the purposes / processing set. Need to figure out what is the common data set collected across all purposes - would be mean data set. This also includes data elements that may not be transmitted to each registry as certain registries may not need it for its purposes. Don't want to push registries to take data that they don't want and need. At the same time, there can be a departure from the minimum data set for registries that do need this additional data. Took out reference to rec 22 - it will still serve its purpose, which will also include consideration of Thick Whois policy. No need to complicate it here by referencing to rec 22. * Consider using "aggregate minimum data set", instead of 'mean' data set. * How can this EPDP overwrite another Consensus Policy? Need further analysis of the impact. Consider referring this to the GNSO Council. * What happens if a registrar doesn't think a registry needs the data, but the registry does need the data? Could create an untenable situation. Seems to remove ICANN's role in this decision of what information is required to be sent to registry. * This group would not be deleting the Thick Whois policy but is saying that the GNSO Council has to look as this and other policies because Compliance with GDPR , as is our mandate, requires it. * EPDP Team has been working on this for a long time now and did not find a justification for transferring all data, but just for a subset / mean data set. Additional data requires additional justification, which can, for some be 6 I b and for some 6 I f. Remember, for 6 I f, a party needs to claim to have a legitimate interest. You cannot force someone to have an interest. * Each purpose has its own data set and its own minimum data set - in this recommendation trying to figure out which data has to be transferred to registries across all purposes (mean data set). * The "Thick" Whois Consensus Policy requires itself to be revised, should conflicts with privacy/data protection law become apparent anyway. So recommendation 5 seems perfectly compatible with it. It should be seen to be helpful to its implementation. * Balancing in relation to thick WHOIS may need to be reconsidered - did not factor in GDPR at the time - not for this team, has to be done somewhere else. Covered by recommendation #22. * Consider better defining or naming the concept of mean data set - aggregate minimum data set. * Not often that the work in one PDP that conflicts with the work of another PDP. No way to reconcile those two. * "Provided an appropriate legal basis exists" that is the work that went into the data elements workbooks. * Important to recognize in the report that the EPDP Team has gone through the details of mapping all the processing activities and legal basis. * Consider posing question to Ruth whether there is a legal basis for transfer from data from registrar to registry under 6(1)b. * Possible rewording: "As part of this analysis, the EPDP Team has identified a set of data elements that are required to be transferred from the registrar to the registry in order to fulfill the Purposes for Processing Registration Data. This set of data elements constitutes an “aggregate minimum data set.” This is an aggregate minimum data set of all identified Purposes that registrars will be required to transfer to registries. This aggregate minimum data set also includes those data elements that MAY NOT be transferred from the registrar to the registry, where such a registry does not require such a transfer (with due regard to that registry’s terms, conditions, and policies)." Action item #4: EPDP Team to further review / consider Data Elements to be Transferred from Registrars to Registries (Rec 5) and put forward proposed language for the Final Report, factoring in today's discussion (that could also be in relation to Rec #22, Impact on Other Policies). Action item #5: Staff Support Team to update Recommendation #5 (Data Elements to be Transferred from Registrars to Registries) in line with edits suggested by Ayden during the meeting. Action item #6: Leadership to work with legal committee on possible question in relation to Thick WHOIS. Margie to provide initial question draft for Legal Team review. 4. ICANN Org Questions (30 minutes) Per last week’s action item, EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report a. Consider topics flagged b. Discuss proposed approach (‘what happens if these topics are not addressed / covered in the Final Report?’) c. Confirmation of agreement reached or next steps to come to agreement * Process for amendments to Registry - Registrar Agreements: objective of this provision was to streamline process for RRA amendments. Might be beneficial to have included in the policy recommendations? Consider addressing this in implementation. Consider adding a general recommendation that would state something like: "policy should include a predictable and transparent process for RRA amendments". Or include under the implementation section language such as: "as part of the implementation, a process for amendments to Registry - Registrar agreements needed to implement EPDP recommendations should be considered". Action item #7: In response to ICANN-raised issues, staff support team to circulate proposed language to address process for amendments to Registry - Registrar Agreements. * Notices to Registered Name Holders Regarding Data Processing - already covered by GDPR, this is too prescriptive, not necessary. Work through in implementation - too specific here. Some of it may still be covered, but to be considered in implementation. No need for policy language that duplicates legal obligations. * Bulk Registration Data Access to ICANN - many registries transferred data that included personal data, this appendix is aimed to clarify that no personal data is to be transferred. Does this rise up to a recommendation level, or is this an action that ICANN could take to notify registries or is this a contract amendment? Better addressed as a contract amendment. Current agreement says that Registry MAY sent a full escrow deposit - now they have to strip it as a result of this provision. ICANN Org does not want to receive a full escrow deposit. What would happen if this provision is not continued. Action item #8: In response to ICANN-raised issues, RySG reps to work with ICANN Org on proposed path forward in relation to bulk registration data access to ICANN. 5. Recommendation #12 – Reasonable Access (30 minutes) a. Review revised proposal b. Discuss revised proposal c. Confirmation of agreement reached or next steps to come to agreement Action item #9: EPDP Team to continue discussion on the mailing list in relation to recommendation #12 (Reasonable Access) in view of coming to agreement by tomorrow's meeting. 6. Review of additional topics raised (if time allows) 7. Wrap and confirm next meeting to be scheduled for Thursday, 7 February 2019 at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Comments on Final Report & Additional Topics- Part 1
by Margie Milam Feb. 7, 2019

Feb. 7, 2019

Hi- Per Marika’s request, here are some language clarifications for your consideration, as well as additional topic submitted on behalf of the BC, and developed in collaboration with the IPC. New Text is in yellow highlight. _________ Rec 1 Purpose 1(b): Subject to the Registry and Registry Terms Conditions and Policies, and ICANN Consensus Policies – please ADD: { and relevant registry agreements and registrar accreditation agreements] Purpose 2: Footnote 6 needs to be moved to be linked to Purpose 2, not Rec 2. Research purpose: The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research ADD: [ and threat response] carried out by ICANN’s Office of the Chief Technology Officer (OCTO). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the expression 426for the need of such data by ICANN Footnote 7/8 should not be a footnote but moved up to the body of the report. These footnotes are substantive recommendations and commitments that should not be buried in a footnote. Rec 7: Replace “ICANN Compliance”with ”ICANN Organization” to be consistent with other recommendations. Delete the quote in Footnote 12 on page 24, since this is inconsistent with Purpose 5. Additional Topics: INFORMATION TO BE PROVIDED TO THE REGISTRANT: Page 16- where there is the quote from the EDPB: It should therefore be made clear, as part of the registration process, that the registrant is free to (1) designate the same person as the registrant (or its representative) as the administrative or technical contact; or (2) provide contact information which does not directly identify the administrative or technical contact person concerned (e.g. admin(a)company.com<mailto:admin@company.com>). For the avoidance of doubt, the EDPB recommends explicitly clarifying this within future updates of the Temporary Specification”. We believe it is important to follow the EDPB’s advice and propose including a recommendation regarding informed consent, in light of the legal advice received, as follows: The EPDP recommends that as part of the registration process, the Registrar shall offer the registered name holder the option to (1) designate the same person as the registrant or its representative as the technical contact; or (2) provide contact information which does not directly identify the technical contact person, but instead uses a generic or role-based email (e.g.admin(a)company.com<mailto:admin@company.com>). OPTIONAL TECH CONTACT DISCUSSION: We do not support making the Tech Contact optional at the registrar level or registry level and believe that more discussion is needed. For example, we have not discussed what happens to existing Tech contacts in the legacy registrations. Shouldn’t there be a similar transitional process to what has been developed for the ORGANIZATION field? In any event, this obligation must be requieeed for the registries since they should receive the tech contact data for those registrants who have provided consent. RECOMMENTATION REGARDING CONSENT Page 19 – Line 549 please delete “as soon as commercially reasonable”. Instead, this recommendation should track the dates for implementation under the transition plan that James and the registrars proposed in Toronto. Rec 4: THICK WHOIS: we do not support the deletion of THICK WHOIS as a consensus policy, and believe that this goes beyond the scope of this EPDP. Rec 8: GLOBAL REDACTION vs. OPTIONAL AT THE REGISTRAR--- We do not agree with global application of the REDACTION, and believe that this recommendation goes well beyond the Temp Spec, which at a minimum allows the registrars/registries to CHOOSE a different application, especially because of differing legal regimes. Our policy needs to be flexible enough to account for laws beyond GDRP, such as the possible US legislation related to WHOIS. Similarly, we do not believe that the redaction should apply to legal persons. We recall James suggesting that we could consider an approach similar to the approach taken for the ORGANIZATION Field, and thus we would like to further explore it in Phase 2. Footnote 15 is a recommendation that should be moved into the body of the Final Report & not be buried in a footnote. Also- it needs to exclude registrations with privacy/proxy services and those for which the registrant has provided consent. PAGE 27: REDACTION OF CITY– we don’t agree with the redaction of CITY and are awaiting legal advice from Ruth on the issue. As a result, it is premature to make a recommendation that it be redacted now. This should be a Phase 2 discussion REC 9: Instead of a “via a process that can be determined by each registrar” we should have concrete steps that can be enforced by ICANN. Could the registrars identify some reasonable steps for this process? ADD: After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar. We are still working through the remainder of the Final Report, and will follow up this email with additional comments. All the best, Margie

7 12

Re: [Gnso-epdp-team] [Ext] Re: FW: Response from ICANN Compliance re. registrations under the 2009 RAA
by Alan Greenberg Feb. 7, 2019

Feb. 7, 2019

Hi Ayden, The issue is not collecting and maintaining. It would be foolish for registrars to have to collect Admin data post-EDPD-policy implementation if the intent is to get rid of the field. All of those registrations where they might collect Admin data, we know that the Registrant contact details are mandatory (since they would be subject to 2013 rules). The issue is we cannot eliminate the field from the database structure (and eliminate disclosing it when applicable) until we make sure there are no empty registrant contact fields. Moreover, as I pointed out in the my previous message, a registration might include Technical contact info but that is not sufficient to replace Registrant/Admin. Here is something that will work. "Recognizing that in the case of some existing registrations, there may be Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." This would ensure that we do not eliminate the Admin fields until we can ensure that every registration (and particularly every registration in the escrow files) has SOME contact info for someone responsible for the registration. That protects the registrant, but does not required Registrars to keep collecting data that is being phased out. The list of fields to be collected would have to note this recommendation instead of just omitting the Admin fields. Alan At 06/02/2019 05:57 PM, Ayden Férdeline wrote: Hi Alan, I have tried to strike a balance between the text I shared earlier and the comments you have raised here. Here is what I have come up with: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain contact information. Can you live with this? I have removed the reference to "some contact", which you found vague, and "name", because you noted this was unnecessary given the RAA. However I have still deleted the last sentence, because I do think it is redundant. Best wishes, Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 6, 2019 5:27 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Now that I have posting rights again: Two comments on "... will contain the name and contact information of some contact" - It is not really necessary to mention "name" since the 2009 RAA did require a Name field for the Registrant. - "some contact" is too wide, since we are still requiring (optionally) a technical contact which may not be the entity responsible for the registration (for instance it my be the hosting provider). Since we are also eliminating the Billing fields, the Registrant is the only remaining non-technical contact, so replacing the phrase with: "... will contain full Registrant Contact information" That also eliminates the need for the e.g. Regarding Ayden's recommendation to eliminate the final sentence, I do not agree. We need to make it clear that ensuring the Registrant contact information being present is a gating requirement to elimination of the Admin fields. We could in fact stop collection admin contact details before that, because for all new or changing registrations the 2013 rules apply which ensures Registrant data. Alan At 06/02/2019 06:58 AM, Ayden FÃ©rdeline wrote: Thanks, Marika. I have some suggested edits, which are stylistic and not substantive: Redline: Recognizing that in the cases of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to in eliminating the collection and maintenance of the current Aadministrative Ccontact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact., e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact. Best wishes, Ayden FÃ©rdeline â��â��â��â��â�144;â€�â��â�� Original Message â�â��â��â��â��â��€�â�� On Tuesday, February 5, 2019 66:18 PM, Marika Konings <marika.konings(a)icann.org> wrote: In line with the comments made, would the following work for inclusion in the Final Report: New Recommendation: Recognizing that in the cases of some registrations, there may be an Admin Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, in eliminating the collection and maintenance of the administrative contact, the Registrar MUST ensure that each registration will contain the name and contact information of some contact, e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. If you have any concerns about this proposed language, please share this with the mailing list by Wednesday 6 February COB. Best regards, Caitlin, Berry and Marika From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, February 4, 2019 at 18:20 To: Kurt Pritz <kurt(a)kjpritz.com> Cc: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] FW: Response from ICANN Compliance re. registrations under the 2009 RAA Kurt, that would be fine. But that is not "elimination of the field". The registrar "ensuring" must happen before the field disappears. We have an escrow program to protect registrants against failures in registrars and registries. The escrow data going forward must always include contact info. I am just about to name an alternate for tomorrow and will lose posting privileges to this list. Alan At 04/02/2019 07:07 PM, Kurt Pritz wrote: Thanks for this Alan: Might another approach be to write into the policy something to the effect that, Ã¢��Recognizing that in thehe cases of s some registrations there is an Ã¢��Adminin ContactÃ¢�but no Registered Name Holder or any otherr contact, it is required that, in the eliminating the collection and maintenance of the administrative contact, the registrar will ensure that each registration will contain the name and contact information of some contact, e.g., the registered name holder.Ã¢�� >Something like that to let each registrar manage its own situation and also to give compliance a way to monitor registrations to ensure that there is contact information. Best regards, Kurt On Feb 4, 2019, at 3:58 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Another alternative is to say that the Admin contacts are not to be collected for new, changed or transferred registrations (which are all subject to the 2013 RAA requirement for Registrant contact data) and that the fields will be eliminated once all registrars confirm that all of the registrations under their sponsorship have Registrant contact information. Alan At 04/02/2019 05:14 PM, Alan Greenberg wrote: I do not believe that we can eliminate the Admin contact information (as currently recommended) without a concrete idea of how many registrations might be left without contact information and just a note that implementation should investigate the potential impact. If that investigation (if it is even possible given the data that ICANN possesses) we to show that there are a substantive number of such registrations, what could they do? We know that registrars have resisted the requirement to take corrective action on registration (which is why the validation/verification requirements in the 2013 RAA only apply when there are changes). If we eliminate Admin fields, we must provide for ensuring that all registrations have contact information within a relatively short period of time. The easy fix given the timeline is to not eliminate the Admin fields. Alan At 04/02/2019 08:19 AM, Marika Konings wrote: Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan GreenbergÃƒÂ¢��s Questistion: br> The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: ÃƒÂ¢��As parart of the implplementation, consideration needs toto be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)ÃƒÂ¢��? ; > Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation forr Asssigned Namees and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

3 2