[Gnso-rpm-sunrise] Actions & Notes: RPM Sunrise Sub Team Meeting 27 March 1800 UTC

Julie Hedlund julie.hedlund at icann.org
Wed Mar 27 19:39:29 UTC 2019


Dear All,

Please see below the action items and notes captured by staff from the RPM Sunrise Sub Team meeting held on 27 March 2019 (18:00-19:00 UTC).  Staff have posted to the wiki space the action items and notes.  Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, AC chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2019-03-27+Sub+Team+for+Sunrise+Data+Review.

Best Regards,
Julie
Julie Hedlund, Policy Director

==

NOTES & ACTION ITEMS

Actions:  Staff will endeavor to capture the draft text of preliminary recommendations and incorporate it into a revised summary table.

Notes:

1.  Updates to Statements of Interest (SOIs): No updates provided.

2.  Development of Preliminary Recommendations (Questions 2 and 3, and 4 if there is time)

QUESTION 2
(Threshold question: Is Registry pricing within the scope of the RPM WG or ICANN's review?)
(a) Does Registry Sunrise or Premium Name pricing practices unfairly limit the ability of trademark owners to participate during Sunrise?
(b) If so, how extensive is this problem?

Tentative Preliminary Recommendation: 1) [Griffin Barnett] Registry Operator pricing should not discriminate against brand owners or otherwise have the effect of circumventing the reasonable use of the Sunrise mechanism. 2) [Susan Payne] Consider a PIC – a registry operator should not operate its TLD in such a way as to circumvent the RPMs.  This would allow for an aggrieved brand owner to enforce via the PIC DRP and not be reliant on ICANN Compliance.

Discussion:
Griffin Barnett: In writing: Registry Operator pricing should not discriminate against brand owners or otherwise have the effect of circumventing the reasonable use of the Sunrise mechanism
Susan Payne: Julie - building on Griffin's suggestion, mine was that we consider a PIC - registry operator should not operate its TLD in such a way as to circumvent the RPMs.  This would allow for an aggrieved brand owner to enforce via the PIC DRP and not be reliant on ICANN Compliance
-- Pricing shouldn't circumvent the RPMs -- ICANN should mandate a pricing level but ask registry operators whether something they are doing might circumvent the RPMs.
-- Pricing recommendations may not need to be taken up with the SubPro PDP WG.
-- Could inform SubPro of progress.
-- Pricing is outside the picket fence.
-- Relates to question 3 -- problem but how we frame it is important.
-- Proposal from George Kirikos -- that Sunrise will be eliminated: consider under Preamble questions.
-- On (a) at a certain price level it affects the decision of the TM owner to take advantage of the Sunrise.
-- Need to be mentioning picket fence.  See: https://gnso.icann.org/sites/default/files/file/field-file-attach/picket-fence-overview-23jan19-en.pdf.
-- Some concern about discriminatory pricing but also that we stay within the picket fence.

QUESTION 3:
(a) Should Registry Operators be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name?

Tentative Preliminary RecommendationS:
1) [George Kirikos] If there's a challenge mechanism, it could be modeled on the Passive Holding doctrine test under the UDRP (with better clarity, as some panelists misinterpret that test).  This would be an Implementation Review Team task.
2)[(Griffin Barnett] ICANN should establish a mechanism that allows trademark owners to challenge a determination by a registry operator that a particular domain name is a "Premium Name" or a "Reserved Name".  The mechanism could be a component of an enhanced Sunrise Dispute Resolution Procedure (SDRP), where the challenger brings the issue to the registry first, with the possibility of an appeal to a neutral third party if the initial direct registry interaction does not result in the desired outcome for the challenger. If the challenger ultimately prevails, the registry operator would be required to change the designation of the domain name at issue such that it is no longer identified as a "Premium Name" or a "Reserved Name" and becomes available for registration by the challenger. As part of the proposed challenge mechanism, a defense, or ground for denying the challenge, should be that the registry must continue to designate a certain name as "reserved" to comply with other ICANN policies or applicable law.
3. [Maxim Alzoba] Since all registries are real-time (or almost real-time (there is no requirement to make it strictly real time with reaction in milliseconds, it is not a stock exchange after all), Registries have to use something saying - 'this should not pass registration '(for example Registrar via SSR (interface of the RO - Registry Operator platform) sent command to register a domain... the answer should be - registered /not , almost instantly (with ability to check - why not) or Check command - to understand what is possible to do, in what state the domain is etc.) – so there is no time for offline checks, and all types of exclusions (due to policies of ICANN, SSAC recommendations, prohibitions due to local reasons, like prohibition of the registration, for example due to decision of the local court, or the regulator -all records are in the Reserved list ...) So changing Reserved list, will affect Registries in their ability to run real time platforms (and it is required - via SLA means in RA (registry agreement with ICANN). And the consequences are quite unpredictable  (including security and stability concerns).

Discussion:
-- If there is a mechanism it will need to have an objective standard.
George Kirikos: @Julie: I was saying that if there's a challenge mechanism, it could be modeled on the Passive Holding doctrine test under the UDRP (with better clarity, as some panelists misinterpret that test).
George Kirikos: @Julie: actual text would be an Implementation Review team task.
Maxim Alzoba 2: NOTE: Registries do not have capacity to talk to all third parties / interact
Maxim Alzoba 2: Registrars are in the mass market business, not Registries
Griffin Barnett: To try and capture my proposal: ICANN should establish a mechanism that allows trademark owners to challenge a determination by a registry operator that a particular domain name is a "Premium Name" or a "Reserved Name".  The mechanism could be a component of an enhanced Sunrise Dispute Resolution Procedure (SDRP), where the challenger brings the issue to the registry first, with the possibility of an appeal to a neutral third party if the initial direct registry interaction does not result in the desired outcome for the challenger.
Griffin Barnett: If the challenger ultimately prevails, the registry operator would be required to change the designation of the domain name at issue such that it is no longer identified as a "Premium Name" or a "Reserved Name" and becomes available for registration by the challenger
Griffin Barnett: (that should be part of my proposal too)
Maxim Alzoba 2: Since all registries are real-time (or almost real-time (there is no requirement to make itstrictly real time with reaction ini milliseconds, it is not a stock exchange after all)- Registries have to use something saying - 'this should not pass registration '(for example Registrar via SSR (interface of the RO - Registry Operator platform)sent command to register a domain... the answer should be - registered /not , almost instantly (with ability to check - why not) or Check command - to understand what is possible to do, in what state the domain is e.t.c) - sothere is no time for offline checks, and all types of exclusions (due to policies of ICANN, SSAC recommendations, prohibitions due to local reasons, like prohibition of the registration, for example due to decision of the local court, or the regulator -all records are in the Reserved list ...)So changing Reserved list, will affect Registries in their ability to run real time platforms (and it is required - via SLA means in RA (registry agreement with
Maxim Alzoba 2:  ICANN).And the consequences are quite unpredictable  (including security and stability concerns).
Griffin Barnett: To also add something quickly to my proposal also:  As part of the proposed challenge mechanism, a defense, or ground for denying the challenge, should be that the registry must continue to deginate a certain name as "reserved" to comply with other ICANN policies or applicable law.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-sunrise/attachments/20190327/74a57d01/attachment-0001.html>


More information about the Gnso-rpm-sunrise mailing list