[GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 15 January 2019

Thu Jan 16 22:33:28 UTC 2020

Dear All,

Per this item in the notes below:

3. Proposed Revised Work Plan/Timeline:  This change requires a Project Change Request to be reviewed and approved by the GNSO Council, per the new PDP 3.0 implementation.

Please see the attached Project Change Request and slides that have been delivered to the GNSO Council for the RPMs PDP WG update at the Council meeting on 23 January.

Kind regards,
Julie
Julie Hedlund, Policy Director

From: GNSO-RPM-WG <gnso-rpm-wg-bounces at icann.org> on behalf of Julie Hedlund <julie.hedlund at icann.org>
Date: Wednesday, January 15, 2020 at 2:49 PM
To: "gnso-rpm-wg at icann.org" <gnso-rpm-wg at icann.org>
Subject: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 15 January 2019

Dear All,

Please see below the action items captured by staff from the RPM PDP Working Group call held on 15 January 2019 at 18:00 UTC.  Staff will post these to the wiki space.  Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-01-15+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG.

Best Regards,
Julie
Julie Hedlund, Policy Director

==

NOTES & ACTION ITEMS

1. Updates to Statements of Interest: No update provided.

2. Complete Discussion of Individual URS Proposals, see attached survey results slides and the wiki at: https://community.icann.org/x/aACNBQ -- Order of remaining proposals: 33 (continue discussion), 15, 22, 4, 14, 13, 17, and 16.

#33:
-- Strike reference to UDRP as it is out of scope.
-- Don’t edit these proposals on the fly.
-- No sure how we would handle this one – not opposed on the concept of getting comments on whether MOU for URS providers should be turned into a contract.  But this issue only exists for registry contracts, so not sure how we handle the context.
-- The term is one of the T's and C's of a contract - much too fine to seek comment on in my view but agree with Phil on overcall contract/MOU point.
-- Not in favor of publishing because it is based on a misunderstanding of the MOU – it is a binding contract and there is no context as to why the MOU isn’t sufficient.
-- The MOU currently is enforceable and also has termination options.
-- If it is published then contextual language should note that URS providers are under MOU, that MOU is a short form contract, and provide a link to the MOU text.
-- Some support for publication.
-- More a question about the terms of the contract and how they are enforced.  May include questions for public comment.
-- The issue when we discussed this before was the presumptive renewal.  That is a issue that might go out for public comment.
-- Keep in mind the MOU incorporates the URS Procedure and Rules, so it isn’t as barebones as it might appear.
-- MOU should not be relegated to letter of intent status or an informal contract. The original agreement for ICANN to govern the internet was an MOU with the Department of Commerce MOU's are often used in governmental services.

#15:
-- How do you know what a registrant is?  Someone could register in someone else’s name and that person could be blacklisted.  No framework to identify who the bad guys are.  It is unenforceable.
-- There are issues about implementation.  But the concept seems like something that the community should comment on.  We should be asking for comment on the concept, even if the implementation isn’t clear.
-- This proposal gets to the heart of whether or not we want the URS to be a deterrent and not just a remedial mechanism.
-- Could note that the proposal was to change the threshold – point that out for context to seek a range of views.
-- Staff notes that based on previous and recent experiences with PDPs, there are a multitude of ways that a WG can solicit comment.  You can put in language in the proceeding or in the report that we are looking for a certain kind of comments.  Break out how and what you ask for with the RPMs.  You don’t need a one-size-fits-all approach.  It can be specific to URS.
-- You could have a general instruction on thresholds that commenters should indicate whether they are two low, high, or otherwise.
-- General support for publication.

#14:
-- Merge with #15.
-- Split on support or not to publish in the survey – but survey notes that they have already been merged.
-- Doesn’t pass the standard as unmerged.
-- Doesn’t specify registrants.  #14 might just be making the penalties reciprocal.
-- Text of the proposal is not substantively different from #15 and staff can merge with #15 in the Initial Report, noting the context in the rationale.

#22:
-- Support for publication.

#4:
-- All providers are on a common platform and are in compliance.  So this proposal is moot.
-- It doesn’t seem that there is any point in asking this question.  The requirement for these formats now exists.
-- No support for publication.

#13:
-- Torn on this proposal.  Support for the idea, but hard to put a barrier on someone’s future actions.
-- Could be a wide variety of opinions on this proposal.  Support for publication.
-- Could bring up a lot of interesting questions.

#17 (related to #16):
-- Confused about this one – doesn’t seem clear re: suspension period.  Confusing to send it out as is.
-- Think this was intending this to apply to the suspension period of the lifecycle of the domain.
-- Should go out for public comment, despite that several WG members disagree with the proposal.

#16 (related to #17):
-- #16 it is effectively a demand to transfer (if the party has the superior rights).
-- Several comments in support for the proposal and indicating that it is feasible.

3. Proposed Revised Work Plan/Timeline:
See: Attached

-- Due to additional activities of the WG including revisiting the URS Sub Team recommendations and individual proposals, additional WG meetings to review the Initial Report draft, and additional meetings to review the public comments the work plan and timeline has been extended.
-- The goal to deliver the Final Report to the GNSO Council now is end of August 2020, changed from end of April 2020.
-- This change requires a Project Change Request to be reviewed and approved by the GNSO Council, per the new PDP 3.0 implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20200116/13410b15/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Project Change Request - RPM PDP WG - 17 January 2020.pdf
Type: application/pdf
Size: 102796 bytes
Desc: Project Change Request - RPM PDP WG - 17 January 2020.pdf
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20200116/13410b15/ProjectChangeRequest-RPMPDPWG-17January2020-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RPM-PDP-WG-Project-Change-Request-to-GNSO-Council-23Jan2020-FINAL.pdf
Type: application/pdf
Size: 261380 bytes
Desc: RPM-PDP-WG-Project-Change-Request-to-GNSO-Council-23Jan2020-FINAL.pdf
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20200116/13410b15/RPM-PDP-WG-Project-Change-Request-to-GNSO-Council-23Jan2020-FINAL-0001.pdf>