Dear All, Please see below the action items and notes captured by staff from the RPM PDP Working Group call held on 05 September 2018 (12:00-14:00 UTC). Staff have posted to the wiki space the action items and notes. Please note that these will be high-level notes and are not meant as a substitute for the recording. The recording, AC chat, and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2018-09-05+Review+of+all+Ri.... See also the attached referenced documents. Best Regards, Julie Julie Hedlund, Policy Director == ACTION ITEMS: Page 6, First Bullet: ACTION ITEM 1: Change “WHOIS” to “WHOIS/RDDS” and “Providers should modify their operational rules in terms of automatically populating the Complaint Form using WHOIS data [using WHOIS/RDDS data consistent with applicant ICANN Consensus Policies]” ACTION ITEM 2: Ask the Providers Sub Team to rework the language. Page 6, Second Bullet: ACTION ITEM: Ask the Providers Sub Team to clarify the notion of developing rules. Page 10: ACTION ITEM: Check that the reference to 4.2 is the intended reference. Pages 27-28: ACTION ITEM 1: Review the language in the recommendations to capture the compliance concept while leaving the implementation details open, but seek community feedback. ACTION ITEM 2: Staff to inquire and then inform the WG which ICANN body is responsible for enforcing URS Provider MOUs -- GDD Compliance, ICANN Legal, or both? NOTES: 1. Review Agenda/Statements of Interest Updates -- Maxim Alzoba: Selected as GNSO Council representative from the Registry Stakeholder Group to be seated at ICANN63. -- Kathy Kleiman: Upcoming update -- starting at Princeton as a visiting scholar. -- Brian Beckham: Updated that he has been an observer to the IGO Curative WG and that he is a Co-Chair of the RPM PDP Working Group. 2. Reminder Concerning the Procedures for URS Policy and Operational Recommendations and Revised Proposal Submission Deadline of COB on September 6th (see attached document) 3. Begin Discussion of URS Policy and Operational Recommendations (see attached Super Consolidated URS Topics Table): Operational Fixes Page 4 -- Proposal: Fully automate the list of cases with a centralized database/single repository of all cases provided in .XML format. The question of how a centralized database would be paid for and managed could be included in the Initial Report to seek feedback as there are different opinions on how to implement the recommendation. For example, this might be achieve via the inclusion of an EPP extension showing that there is a pending URS/UDRP proceeding, although this would require at least 180 days for implementation. -- Rule 3(g) “A URS Complaint may not be filed against a domain name that is part of an open and active URS or UDRP case” governing the overlapping of cases suggested that the implementation of this operational fix should be in the form of a suggestion, rather than a policy. It could become part of the Providers pre-action checklist. WG Agrees with the operational fix and on seeking feedback on ways to implement it. Page 6: First Bullet: -- Rationale for the operational fix: Post GDPR many complaints will be brought where the registrant is unknown. The Sub Team wanted to find a way to update the complaint to be able to indicate who the registrant is. ACTION ITEM 1: Change “WHOIS” to “WHOIS/RDDS” and “Providers should modify their operational rules in terms of automatically populating the Complaint Form using WHOIS data [using WHOIS/RDDS data consistent with applicant ICANN Consensus Policies]” ACTION ITEM 2: Ask the Providers Sub Team to rework the language. Second Bullet: -- Rationale for the operational fix: UDRP Rules, para 4(a) and 4(b) on the notion of a registry responding to a request. -- The public should have input on the development of any rules. Could change to "proposed rules that are approved by the GNSO". -- Note that the URS is currently not a Consensus Policy, so it is binding on registry operators via contract. Anything we would propose would require sufficient lead time and discussion. ACTION ITEM: Ask the Providers Sub Team to clarify the notion of developing rules. Page 10: WG agrees that ADNDRC should change its operations to come into compliance. There is a separate question of compliance generally and which topics fall into that general category. General suggestion: when the WG develops the text for the recommendations and proposals for the Initial Report, the text should be changed to phrase it without mentioning a particular provider. ACTION ITEM: Check that the reference to 4.2 is the intended reference. Page 11: -- There is a GDD portal through which ICANN contacts registries and registrars, but not sure we need to specify that at this point. There is no third party access currently. Best we could expect is that URS Providers could view the current list of contacts. WG agrees with the operational fix on the need for ICANN, Registries, Registrars, and Providers to have access to up-to-date contact information and for interaction. Page 16: -- Rationale for the operational fix: Envisioned that this would be a light recommendation to supplement existing policies, rather than creating a new policy. -- Possible questions for feedback in the Initial Report: Who would pay for this and does it also apply to examiners? Who would have responsibility for the overarching guidance repository? -- Educational materials should be made public. -- Note that this language was recently modified in the last iteration of the Super Consolidated document. -- Could be a more generalized suggestion, with this language being a possible implementation detail. -- Suggested including the text: "Any materials should be translated in the UN 6 languages." WG agrees with the operational fix on the need to develop educational materials, but wording could be rephrased to leave out specific implementation details, such as hiring Researchers/and or Academics. Page 17: -- Possible questions for feedback in the Initial Report: Who should have the responsibility to develop guidance and pay for the development? WG generally agrees with the operational fix that there should be guidance for practitioners and examiners; companion concept would be for a checklist; also in general for the public, including registrants and complainants. Page 27: -- Seems to be an umbrella theme of compliance. -- Could apply to URS and UDRP, but there doesn't seem to be a reason to hold up a recommendation for the URS. -- Is this a job for ICANN Compliance (which enforces Registry/Registrar contracts) or for ICANN Legal? The Providers MOUs are entered into by ICANN. So perhaps it should be just ICANN. -- There is a difference between monitoring and responding to complaints. Monitoring is a larger undertaking/responsibility. Typically ICANN Org does not continuously monitor these types of issues; a complaint is first filed. -- A Provider could be subject to an audit. -- The MOU contains a termination clause for Provider's failure to comply with terms of MOU or the URS Procedures or Rules. -- Question to staff: Is it already possible to register a complaint through ICANN's complaint portal? Answer: For the URS typically these are handled by ICANN Compliance. The complaint or question must first be addressed to the URS Providers directly. There also are forms where a Provider or a Complainant can file a complaint. See: https://www.icann.org/resources/pages/urs-2013-10-31-en. WG generally agrees with the operational fix, but may ask the WG to reword it with respect to either proactive or reactive monitoring by ICANN. Pages 27-28: -- Any thoughts on how this effort could be achieved? Registries and Registrars must comply with their contracts and there are already ways to enforce compliance. URS is a policy both Registrars and Registries have to follow, and it is enforceable (Registry has to lock in 24 hours), but there is an implication with an extension for a year. -- There is a gap throughout the recommendations: database, compliance monitoring, publication of educational guides. Consider as a WG whether there needs to be some kind of URS/UDRP Commissioner to provide oversight, or an Ombudsperson for URS/UDRP. Could also be a standing advisory committee; however, there is a big distinction between the advisory committees and other structures under the Bylaws. -- There is an effort in the GNSO to review all consensus policies. Also, for PDP WGs to include metrics. Some WGs are developing recommendations for when and how policies could be reviewed. The WG could consider these points. WG generally agrees with the operational fix and the concept of increased monitoring and/or compliance. The WG should seek community feedback on how to implement/activate. ACTION ITEM 1: Review the language in the recommendations to capture the compliance concept while leaving the implementation details open, but seek community feedback. ACTION ITEM 2: Staff to inquire and then inform the WG which ICANN body is responsible for enforcing URS Provider MOUs -- GDD Compliance, ICANN Legal, or both? Page 33: The WG has discussed already in detail and agrees with the operational fix. Page 39: -- The WG may want to reword the operational fix so that it is not specific to ADNDRC. -- there are individual proposals which suggest rewording of Rule 6(a) "Each Provider shall maintain and publish a publicly available list of Examiners and their qualifications". See: https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals The WG agrees with the operational fix, pending discussion of related proposals.