January 2020 - GNSO-RPM-WG - lists.icann.org

Results re: Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time
by Julie Hedlund Jan. 10, 2020

Jan. 10, 2020

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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Friday, January 10, 2020 at 10:41 AM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, January 8, 2020 at 4:28 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, January 8, 2020 at 4:13 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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+R…. 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.

1 0

REMINDER: Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time
by Julie Hedlund Jan. 10, 2020

Jan. 10, 2020

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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, January 8, 2020 at 4:28 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, January 8, 2020 at 4:13 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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+R…. 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.

1 0

REMINDER RE: Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time
by Julie Hedlund Jan. 10, 2020

Jan. 10, 2020

Hi Susan, Thank you very much for your comments. Staff notes that if the WG decides to change to 18:00 UTC for subsequent meetings starting next week, unless the WG were to decide otherwise the plan would be to revert to 17:00 UTC upon the change to US daylight saving time in March 2020. Kind regards, Julie From: Susan Payne <susan.payne(a)valideus.com> Date: Friday, January 10, 2020 at 7:55 AM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)icann.org> Subject: [Ext] RE: Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time Hi Julie My strong preference is to keep the call at the current time. We only actually have a few weeks before Cancun, since that is early March, after which the northern hemisphere is back on daylight savings anyway and presumably this occasional problem goes away. If you do switch the time to 1800-1930 UTC then I oppose that time remaining fixed after daylight savings starts (since at that point the calls become 1900-2030UK and much later for other Europeans) and would ask that we switch back to the 1700UTC slot. Thanks Susan Payne Head of Legal Policy Valideus D: +44 (0) 20 7421 8255 T: +44 (0) 20 7421 8299 M: +44 (0) 7971 661175 E: susan.payne(a)valideus.com <mailto:susan.payne@valideus.com> www.valideus.com [valideus.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.valideus.com_&d=DwM…> From: GNSO-RPM-WG <gnso-rpm-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: 08 January 2020 21:28 To: gnso-rpm-wg(a)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(a)icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund(a)icann.org<mailto:julie.hedlund@icann.org>> Date: Wednesday, January 8, 2020 at 4:13 PM To: "gnso-rpm-wg(a)icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg(a)icann.org<mailto: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+R…. 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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…>

1 0

Response Requested: Question re: Possible Change in RPM PDP WG Meeting Time
by Julie Hedlund Jan. 10, 2020

Jan. 10, 2020

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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, January 8, 2020 at 4:13 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)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+R…. 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.

2 1

Actions: RPM PDP WG Meeting 08 January 2019
by Julie Hedlund Jan. 8, 2020

Jan. 8, 2020

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+R…. 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.

1 0

Post Call | Review of all Rights Protection Mechanisms (RPMs) in all gTLDS PDP WG | Wednesday, 18 December 2019
by Terri Agnew Jan. 8, 2020

Jan. 8, 2020

Dear all, All recordings for the Review of all Rights Protection Mechanisms (RPMs) in all gTLDS PDP WG call held on Wednesday, 18 December 2019 at 17:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_ZIzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-rpm-wg/> and the main wiki page<https://community.icann.org/x/wCWAAw>. Thank you. With kind regards, Terri

2 1

REMINDER: Proposed Agenda for RPM Meeting on Wednesday, 08 January 2020 at 17:00-18:30 UTC
by Julie Hedlund Jan. 6, 2020

Jan. 6, 2020

Happy New Year RPM WG members, Please see as a reminder the agenda below and attachment for the meeting next week on Wednesday, 08 January at 17:00-18:30 UTC. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, December 18, 2019 at 3:01 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)icann.org> Subject: [GNSO-RPM-WG] Proposed Agenda for RPM Meeting on Wednesday, 08 January 2020 at 17:00-18:30 UTC Dear RPM WG members, Please find the proposed agenda and materials for the WG meeting on Wednesday, 08 January 2020 at 17:00-18:30 UTC. Draft Proposed Agenda: 1. Review Agenda and Updates to Statements of Interest 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. AOB Best Regards, Mary, Julie, Ariel 1. Procedure for handling individual proposals at each of the December meetings: * The proposals will be reviewed in the following order - begin with a proposal that received the highest level of support for inclusion in the Initial Report, followed by a proposal that received the lowest level of support for inclusion, then a proposal that received the next-highest level of support for inclusion, followed by one that received the next-lowest level of support, and so forth, until all proposals have been reviewed. Based on this procedures, here is the order of the proposals: 2, 23, 1, 8, 34, 35, 11, 18, 27, 20, 36, 32, 3, 30, 26, 7, 28, 19, 29, 5, 31, 21, 6, 33, 15, 22, 4, 14, 13, 17, 16. * For each proposal, where a Working Group member had indicated (by the December 1 deadline) that he/she wished to argue in favor of including the proposal as an actual Working Group recommendation, that member will be given no more than 3 minutes to make his/her case, with questions and answers (limited to 2 minutes per question or answer and two inputs per member). * Members are kindly requested not to rehash arguments/discussions and to keep their remarks, questions and answers very brief. * Subject to a determination by the Chairs, proposals with wide support and virtually no opposition will be considered as recommendations by the WG. * Proposals with wide support and limited opposition will be published for comment in the Initial Report as individual URS Proposals. * Proposals with virtually no support and significant opposition will not be published in the Initial Report. * Following the Working Group’s review of all individual URS proposals, and in accordance with role ascribed to Working Group chair(s) under the GNSO Working Group Guidelines, the Working Group leadership team will determine whether there is sufficient support from other Working Group members: (i) to “convert” any individual proposal (where one was so argued) to an initial recommendation for purposes of the Initial Report; (ii) to include specific individual proposals in the Initial Report as proposals only; and (iii) to exclude the remaining individual proposals from the Initial Report (although these will all be referenced in the report, with links provided to the actual text of the proposals and the Working Group’s deliberations).

1 1