Dear All, Thank you to all who responded. Based on the responses there is support for moving the WG weekly meetings to 18:00 UTC for 90 minutes on Wednesdays, beginning with the next meeting. Note, however, unless the WG decides otherwise upon the time of the US change to daylight saving time (DST) in March 2020 the time will revert to 17:00 UTC. Kind regards, Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Friday, January 10, 2020 at 10:41 AM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] REMINDER: Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time Dear All, Per the request below, please send your responses no later than COB today, Friday, 10 January. Kind regards, Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Wednesday, January 8, 2020 at 4:28 PM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time Dear All, Per the action item below from today’s meeting, WG members are requested to indicate whether they would be available to attend the weekly WG meetings if they are moved from 17:00 UTC to 18:00 UTC for 90 minutes (18:00-19:30). The request comes from some of the WG Co-Chairs as they have experienced occasional conflicts with the meeting time of 17:00 UTC. As noted during today’s meeting, PDP WGs typically keep the same time in UTC throughout the year, rather than changing the time based on changes between daylight saving time and standard time in the US or other countries. This WG has maintained the same time in UTC for the last few years as do the other PDP WGs. However, the time is dependent on the availability and preferences of the Co-Chairs and the WG members. If the majority of WG members would be available and prefer meeting at a different time in UTC the meeting schedule can be changed accordingly. Kind regards, Julie Julie Hedlund, Policy Director From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Wednesday, January 8, 2020 at 4:13 PM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] Actions: RPM PDP WG Meeting 08 January 2019 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 08 January 2019 at 17: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-08+Review+of+all+Ri.... Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: Meeting Time: ACTION: Staff will ask whether WG members would be able to attend the WG call if it is moved to 18:00 UTC, nothing that the standard is to maintain the same UTC time year round as this WG and others have been doing, do at 17:00 UTC. Notes: 1. Updates to Statements of Interest: -- Susan Payne: I am now a member of the Independent Review Process Implementation Oversight Team (IRP-IOT). Although this was notified back in Montreal the formalities of getting added to the group have taken a while. 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: 3, 30, 26, 7, 28, 19, 29, 5, 31, 21, 6, 33, 15, 22, 4, 14, 13, 17, and 16. #3: -- This proposal seems to be aimed at addressing a scenario after the registry lock has been applied while the proceeding is ongoing. If that is what this recommendation is speaking toward then no objections. -- Some confusion about the wording. -- Suggest we look at how the renewal issue is handled under the UDRP and perhaps use that info to clarify the language of this proposal a bit so it is very clear. But happy to defer that until post-public comment (and we can include some suggestions for clarifying in public comment so as to not delay the process now. -- Provide some explanatory context in the Initial Report. #30: -- Very strongly oppose this proposal. Mandatory mediation would simply drag out what is intended to be a rapid procedure unnecessarily. I recognize that is a substantive ground for opposing rather than procedural in terms of threshold for publishing for comment. - Strongly oppose. Out of scope. -- Could revisit in Phase II with UDRP. -- Would like to see voluntary, but not mandatory. -- Good intention but I don't see how parties can be compelled to undertake mandatory mediation. If parties don't want to then they will simply decline. So oppose for publication. -- Survey reflected a certain level of support. #26: --- Not opposed to proposal 26, but I think most if not all providers do already publish their roster of examiners, although may not take the further step of identifying number of appointments and links to cases by each examiner (beyond the general publication of all decisions). -- Could ask the community as to whether the providers can have some flexibility in complying. -- Not a lot of opposition. #7: -- Do we have the authority/scope to recommend a change to WHOIS to add a new contact field, as this proposal suggests? -- This isn’t a field in the WHOIS. Not sure what purpose it serves to put it out for public comment. -- We could let the EPDP know that this is something that came up. -- Strongly oppose. Although the concept of providing notice is a good thing, unless I have a retained client I don’t want to receive notice. Raises a host of issues that may be unintended. -- There were previous discussions on adding legal contact to WHOIS so we might put it out there just as a suggestion if the option exists. -- Not sure that Legal Contact is a legal counsel per se. Having said that, I'm not convinced this is necessary. Admin Contact is sufficient, that person can deal with notice accordingly. #28: -- Providers already implement conflict of interest measures... they may differ slightly by provider, but wondering if we need to address this at the PDP level? -- I think it is provider specific, as in providers themselves have one. -- Yes - providers each have internal conflicts policies that they employ, it’s just not a single uniform one... Also take that there may be concerns about proper compliance with these policies, but that is not a policy question, but rather an implementation/compliance issue #19: -- Strike the reference to UDRP (thoughout all proposals). -- Covered with #18 and #20. #29: -- This is cost-prohibitive for providers, particularly in URS where we don’t get a lot of filing fees. We’d have to translate a bunch of templates, etc. -- Suspect it would benefit few. Goes beyond a mere technical fix. -- Rationale is to create a form that could be easily analyzed and lots of cases could be reviewed without going through them case-by-case. -- Interesting point about the word 'all' - seems to require retroactive application - will be interesting to see what public thinks if this goes out. #5: -- Several members oppose the proposal. -- Some comments in support, some against. -- SOL from creation date makes no sense, as bad faith can take place much later in the domain lifecycle
no - creation date of the domain name. -- Creation date - this is George's argument that it's the first registration date that should set the date for limitation purposes and not any dates of subsequent transfer. -- Registration date versus creation date – registration date could mean acquisition by a new owner. The original owner could sell to a bad actor who then implements bad faith use – that would be seen as a new registration date, but not creation date. -- I am strongly opposed to the proposal, but it does have some support (and lots of opposition) to publication. If we publish we need to ensure the public understand what "creation date" means. -- The point of the proposal is a time limit for filing complaints. The example was “creation date”, but the specific implementation to be considered/decided by an IRT. -- Agree that if it goes out for publication, then it must explain the terms "creation" and "registration". -- Many years ago there was a question under UDRP jurisprudence whether a renewal constitutes a new registration date but it has been pretty well settled for a while that it does not, without an attendant change in registrant. -- May need to put this proposal out for discussion with some contextual explanation to get feedback on time limits and laches. -- An effective SOL for filing complaints is a valid issue for publication. -- Needs a lot of work before putting it out for comment. -- Mixing up two types of law here – URS is contract law. Need to consider whether it’s appropriate to suggest imposing a British/Canadian/US version of the law on the rest of the world. -- Renewal is not a new registration. The line of case that started to support that proposition were rejected by panelists as a group, Proposal 5 would be a major change in policy. I would reject this proposal and perhaps include a separate proposal as to whether or not there should be a limitation period in URS cases. But this proposal is not workable. #31: -- In general support to put out for public comment. #21: -- This was merged with 22 when the IPs were previously reviewed. -- Very very strongly opposed to this as an overarching principle on such a lightweight RPM as URS as it will be used to bully registrants. -- Merge with 22. #22: -- There will be lots of nastygrams and most uninformed registrants will just not start a legitimate non competing business on a different domain. -- There are a handful of related proposals (like #21 and #22). -- I just don't see how this could work. At best I think we could request public comment on whether this should be studied. -- Need to ask which costs a loser would have to pay. -- A 50/50 split indicates to me that we should publish the issue for public comment and further discussion. -- Knowing that this may happen could have a deterrent effect on bad actors. -- Loser pays as a concept has a lot of nuance, including whether the loser participated in good or bad faith. -- Will also inform future debate re same issue(s) to be presented in Phase II re UDRP. -- I would be interested on hearing from the broader community about (a) if/how this could be implemented and (b) in a way that wouldn't further slow down the URS process. Also, as Mike R. noted, this is surely to come up in Phase 2, so a preview on how the community is feeling about this might be helpful.
 -- Registrant bought the domain name reg using some payment method, so there is some means by which a URS fee could be charged to that same payment method, enforceable via the domain name registration agreement. -- Makes sense for UDRP. The problem here is that it isn’t correct to look at support/non-support as 50/50 in the survey. It’s one thing to ask if loser pay should be in URS and another if someone can put a bond in escrow to protect themselves. -- Beyond no mechanism and being effectively unenforceable, this concept would boost toothless threats and bullying. -- Issue is that we are going far afield from what the URS was created for, which was to be fast and efficient. These may seem desirable in concept, they are inconsistent with the intent of the URS. -- There are arguments on both sides, but the question is whether this is doable. These are fairly extreme methods. Not sure this is the place for us to say that we should have a user pays model. We could ask the public whether it should be studied. -- Should we ask for comment on issues for a user pays model to help inform Phase 2. -- Yes - put the question out for public comment... maybe we ultimately decide no consensus to make it a WG recommendation and that's fine but should put out for comment to collect the feedback
(that comment was re 21/22). -- It will solve very little because under the new ICANN model for new gTLDs and now .info and .org etc can charge $000s not only to buy the name but to register it every year – all they have to do is call it a premium name. URS & UDRP won't help. #6: -- Proposal doesn’t seem to be clear. -- Like a mutant form of consolidation or class action. -- Would involve an extremely small number of cases. -- Some support to put out for public comment. -- Purpose: to facilitate joint complaints by multiple unrelated complainants against a single registrant who has registered many domains targeting multiple TMs of multiple parties - would be a very small subset of cases. -- Odd fit for URS. #33: -- I do think this would be tough to handle and could lead to massively long decisions depending on number of parties and marks involved. If there was to be such a possibility it would seem the fee would need to go up (perhaps each complainant would have to pay a fee) to cover the administrative and panelist time spent on these types of matters. But, essentially, this should be put out to the community -- Continue discussion on the next call. 3. Meeting Time: ACTION: Staff will ask whether WG members would be able to attend the WG call if it is moved to 18:00 UTC, nothing that the standard is to maintain the same UTC time year round as this WG and others have been doing, do at 17:00 UTC.