- 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

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

Dec. 18, 2019

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 0

Actions: RPM PDP WG Meeting 18 December 2019
by Julie Hedlund Dec. 18, 2019

Dec. 18, 2019

Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 18 December 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/2019-12-18+Review+of+all+R…. Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: #27: -- ACTION: Look at the Sub Team recommendation and check with Zak to see if it’s already covered. Sub Team Recommendations: “The WG recommends that public comment be sought on the following questions: - What compliance issues have Registries and Registrars discovered in URS processes, if any?  - Do you have suggestions for how to enhance compliance of URS Providers, Registries, and Registrars in the URS process? The WG recommends that the ICANN Org establishes a compliance mechanism to ensure that URS Providers, Registries, and Registrars operate in accordance with the URS rules and requirements and fulfill their role and obligations in the URS process.” Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Individual URS Proposals: 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. See all proposals at: https://community.icann.org/x/aACNBQ #11: From 11 December meeting: -- Get comment on other possible numbers (3-15, not just on 3). -- Although in general 3 is sufficient to demonstrate a pattern, agree to asking for Public Comment on the appropriate number to demonstrate a pattern. -- Noting the comment on commercial plans, agree to increasing this to 5 -- but getting input on the number appropriate -- Maintain the proposed language and reduction to 3. -- Continue discussion at the next meeting and on the other proposals. From 18 December meeting: -- Don’t support putting it out as it stands. Verification is not defined and no idea how idea how you figure out if someone is a registrant. 3 also is really low. -- We are here to address as to whether there is support to put the proposal out for public comment, not asking for substantive comments on the proposal. -- Don’t believe there is additional delay through this proposal, but a part of the process. -- The "confirmation" part is the problem that extends the URS, which for other proposals is a reason not to support them. -- At the Forum the response fee for 15-50 domains = $400. URS is a very low cost and as a result has very few safeguards and the 3 proposal is very low, so low that it could be used to deter genuine use. -- The number was a question that had been included in being put out for comment -- Support putting this out as 2-part question: should threshold be reduced & input on #. But will need context. -- Seems to be sufficient support for publication, with some opposition. Offer as a two-part open-ended question. #18: -- Addresses a situation that has actually taken place. -- One member opposes public comment. -- One member supports public comment with a menu of proposals (with #19 and #20). -- Note that UDRP is out of scope for the Phase One Initial Report, so don’t support publication. -- For those who don’t support publication there is some support for #20. -- Confusing because of the conflation with the UDRP. The problem that was encountered wasn’t a URS problem because in the URS you have an appeals path. -- Don’t think this is clearly enough explained to recommend going out for public comment. -- We can’t solve for bad complaint-drafting by someone seeking civil litigation to address a URS decision. -- That's why this proposal is to set aside the decision: it ensures that there is a case or controversy regardless of the local law about arbitration/potential tortious interference w/business or other grounds. -- On the contrary, as you know unless there is an ACPA or similar claim, the use of a domain name does not give rise to trademark claims. Precisely why the UDRP/URS ADR procedures were adopted. -- That is not an accurate description of US law--plenty of 32 and 43(a) claims about domain names exist and existed. Not aware of any jurisdiction that declines to evaluate domain names under ordinary TM law even if there are also additional rules but maybe you can provide examples. -- #18 – The URS is complicated enough without bringing this framework from British Columbia; #19 – 38% support for publication, there is enough of an issue to consider putting it out for public comment; #20 – very low support combined. Not worth publication. -- Do not believe Proposals 18, 19, or 20 should be presented for public comment as having substantial opposition and minimal support. -- Some support for #19 and #20. #19: -- Some support for 19 in the chat. -- 4 of 5 comments supported, but that is not representative of the 65% that did not support. -- Moved past an issue to a remedy without showing that the issue exists. -- Oppose 18, 19 and 20. These are not workable or appropriate proposals. -- Support publishing to get thoughts on whether there are alternative ways to deal with the problem. -- What are the grounds for vitiation? Taking a term out of context. -- Point would be not that the decision would be set aside – but the complainant and respondent would be in the same position as though the URS did not exist. -- But the proposal says “set aside” and offers no alternative route. -- This is a proposal to dismantle URS and UDRP – we are here to revise them, not dismantle them. -- I along with a substantial minority (bearing in mind the make-up of the survey participants) support it going out for publication and haven't completely made up my mind whether I support it in substance or not. -- It says if a court finds no cause of action - i.e. the person appealing the URS decision has filed claims with a court and the court has ruled that there is no cause of action - then the URS decision is set aside... it does not suggest any other route to reaching a substantive decision regarding the disposition of the domain name... and as Paul M said it would seem to basically undermine the entire URS process #20: -- Very misguided and dangerous proposal. US courts are under no compulsion to follow it. -- Not sure if it is even possible. #27: -- Support for publication. -- Is this already addressed by Sub Team URS recommendations? Is this really needed. -- Already covered by the existing URS rules. -- Distinction from the current rules is to keep the Curriculum Vitae current. -- ACTION: Look at the Sub Team recommendation and check with Zak to see if it’s already covered. Sub Team Recommendations: “The WG recommends that public comment be sought on the following questions: - What compliance issues have Registries and Registrars discovered in URS processes, if any?  - Do you have suggestions for how to enhance compliance of URS Providers, Registries, and Registrars in the URS process? The WG recommends that the ICANN Org establishes a compliance mechanism to ensure that URS Providers, Registries, and Registrars operate in accordance with the URS rules and requirements and fulfill their role and obligations in the URS process.” #32: -- Not substantial support for publication. -- If it can’t become consensus then don’t publish? -- Is this related to David McCauley’s proposal? Could they be combined? From David: Subtle distinction: the proposal under #31 was made on behalf of Verisign – a proposal to seek public comment on whether the URS should be made consensus policy (not that we are suggesting that it be consensus policy). -- 32 really consists of two proposals: (1) eliminate URS; (2) URS should not be consensus policy applicable to legacy gTLDs -- We are not chartered to dismantle RPMs: "In addition to an assessment of the effectiveness of each RPM, the PDP Working Group is expected to consider, at the appropriate stage of its work, the overarching issue as to whether or not all the RPMs collectively fulfill the purposes for which they were created, or whether additional policy recommendations are needed, including to clarify and unify the policy goals. If such additional policy recommendations are needed, the Working Group is expected to develop recommendations to address the specific issues identified." -- Outside the scope of the charter. -- Seems to be putting the question in the form of an answer. That the proposal is to eliminate it. -- Okay to raise the question (as in #31) as to whether the URS should be consensus policy. -- Seems to be support to not publish it. #36: -- Between the URS procedures section 6 on default and section 12 on appeals --- where a respondent doesn’t reply in case of a default there can be as many as 3 de novo appeals. Under 6.4 they have up to a year for a de novo review and in section 12 there is another de novo review. Asking if we should limit to one de novo review. -- Trying to streamline areas that are duplicative. -- Support from several members to put out for public comment. -- Doesn’t seem to be evidence based. -- There has been no use of the duplicative repeated de novo processes afforded under the URS. So yes, this proposal is based on the evidence of lack of use. -- Significant change from URS rules. If we put it out for comment we should provide the context in the current rules. -- Question: Is the standard here that we put the language as written out? Can commenters make wordsmithing changes? -- This was not a sub team proposal, but was supported by a number of individuals. -- The outcome sub team discussion of the de novo review, per the table, is: “NOTE: There is no WG recommendation at this time. The Documents Sub Team recommends that the full RPM Working Group assesses Individual Proposals #8 and #36 and determine whether any of them can rise to the level of Working Group recommendation.”

1 0

Proposed Agenda for RPM Meeting on Wednesday, 18 December at 17:00-18:30 UTC
by Julie Hedlund Dec. 16, 2019

Dec. 16, 2019

Dear RPM WG members, Please find the proposed agenda and materials for the WG meeting on Wednesday, 18 December 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: Complete the discussion on Proposal 11 followed by proposals 18, 27, 20, 36, 32, 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 0