Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

Super helpful Mary. Thank you.

I think it's defined below.

Is there a link to this? I can't see 3.2.4's factors

Maybe say "and other indicators of source or quality"?

Is there a link to this? I can't see 3.2.4's factors

I like Mary's suggestion. It's similar to what I offered.

verbally and in the chat

Yes, we can do that. Thank you Phil, Lori, Paul and everyone who’s contributed to this text.

My apologies for the disruption.

EU quality schemes: https://ec.europa.eu/info/food-farming-fisheries/food-safety-and-quality/certification/quality-labels/quality-schemes-explained_en

Hard to comment on this without being able to see anything below the introductory clause of 3.2.4. Wish there were a link to the document.

I think Phil made a good point about the third item under 'Proposed policy principles' - seems more explanation than principle and may best be handled elsewhere for the implementation team

here you go Paul M https://mm.icann.org/pipermail/gnso-rpm-wg/2020-August/004406.html

Will there be notices sent to potential registrants based on items in 3.2.4? I understand they won't be ICANN Claims Notices, but will there be notices?

@Paul, I think 3.2.4 is about voluntary additional services, not mandatory RPMs.

How about for 3.2.4 "...and not eligible for Claims or Sunrise or any other pre-registration notices for potential registrants are:"

I don't want to get a nastygram if I go to register champaign.illinois

Agreed

Mozzarella is a TSG. I don’t think that should get the same protection as a GI.

hand up

over to Ariel

Phil as Sub A chair I would be happy toalternate reading these with you if you wish

ok

I don't think the current data supports eliminating the start date sunrise. Most were end date at the time we reviewed this, but that doesn't really llook so clear-cut now: https://mm.icann.org/pipermail/gnso-rpm-wg/2020-August/004406.html

INTA is not opposed to keeping both. We just suggested a simplification. Have 2 standards may be confusing.

in start date sunrise, 30days in advance for notification, and then 30days of start date sunrise

in absence of new info we should not restart already discussed items

@Maxim, yes, the WG’s discussions were clear about the duration of each type of Sunrise Period. If the recommendation text is not clear, we can update it as a textual (non-substantive) change.

+1 Susan

Need to keep Spec 13 exemption

Sorry to join late, had a conflicted call at 1 that just ended

sorry old hand

right. one has notice. the other does not...if I remember correctly.

Ariel, re your notes - no makes perfect sense to do a new exemption for the code of condict exempt ones. Spec 13 already have an exemption and so comments were flagging that this recommendation wasn't intended to change that

INTA does not feel strongly about it's recommendation.

Thanks Susan - we will check the recording/transcript after the call to ensure accuracy

Re Sunrise rec #6 (and others that similarly recommend keeping the status quo): staff will likely look at placing this type of recommendation in its own category for the Final Report (or otherwise indicate which are “status quo” recs).

Please note that staff do not transcribe the meetings. But we do rely on the transcript when summarizing deliberations.

+1 Susan

Thanks David!

for avoidance of doubt, exempting the code of Conduct exempt TLDs IS a change (except for the subset of spec 13 TLDs who are already exempt)

@Phil and all: Staff is capturing the deliberations from this meeting as is usual in the analysis/summary document.

From ICANN org’s perspective as regards implementation, we think you just need a clear sentence somewhere that specifically clarifies this rec doesn’t apply to Spec 13 (and Spec 9 if that is added).

Thanks Mary

Spec 9 is the Registry Operator Code of Conduct

Spec 9 is a code of conduct as I recall, read it a while ago

Spec 9 text: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification9

And yes, it’s RO code of conduct.

new hand

Certain TLDs have been granted exemptions from Spec 9 where they are planning to operate the TLD as a closed TLD but not as a .Brand

The exemption language is in Section 6: “Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for the exclusive use of Registry Operator or its Affiliates, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest.”

What's the overlap of Spec 9 and Spec 13?

Spec. 9 examples are .catholic and .broadway

This seems beyond the scope of what we've discussed in the past.

@Phil, that’s correct - so the idea is consistency as between Spec 13 dot-brands and those ROs that are exempt under Spec 9.

.med

.living

.helsinki

@Kathy surely that's the point. It was a new suggestion coming out of the public comment which we are supposed to be considering

new hand

This is not new.

Agree. Not new.

Part of the RA

We have not clear definition of this small, odd group.

no clear definition

The staff understanding is that this will NOT change the substance of Rec 6, merely clarify that those registries that, by contract (Spec 13 and/or Spec 9) are not expected to run Sunrise periods.

I don’t have a particularly strong feeling on this, but the rationale for exempting Spec 13 TLDs from Sunrise, which is that they are closed registries where names can only be allocated to the registry or affiliates, extends to Spec 9 exempt TLDs, which also limits registrations to the RO only

+1 Susan - public comment needs to be a meaningful exercise.

Bc the general public won’t be registering names in these TLDs, the theory is that they are not likely to be targets for cybersquatting, which Sunrise was meant to avoid through defensive registrations

we could make it even clearer, Mary, by telling IT that we simply mean that those registries that do not register to third parties need not do sunrise - if they do accept third parties, even one, then sunrise - could give direction to IT

@David, for sure.

", unless otherwise exempted."

Let's include more background material when this comes back to the WG

everyone should understand it fully when it comes back

Fine with that path forward, and no objection to shoring this discussion up with additional background for those who aren’t familiar with or don’t understand Spec 9 and the Spec 9 exemption

But agree that the rationale that led to Sunrise exemption for Spec 13 TLDs would logically extend to Spec 9 exempt TLDs as well

(i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty;(iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty.

Contextual language of the recommendation: https://community.icann.org/display/RARPMRIAGPWG/Sunrise+Recommendation+%237

We will

@Susan - we can simply add a sentence to the contextual language that is retained, to say this rec clearly addresses two different dispute processes. It’s not a major concern, just a point of clarification.

Row 22-23

https://docs.google.com/spreadsheets/d/1xMehg9o44bdz85ry0LJvhzoOaKdmJ6SwIrLneMx0Ixc/edit#gid=872694278

I think the INTA/GBOC comments referred to the requirement to avoid abusive Sunrise practices, which I believe is captured in another recommendation

@Griffin, yes I think that’s right.

(Abusive practices by ROs that is)

I think the IPC comments are in a similar vein as well

Agree nothing new here, think we move on

I think we discussed that a bit when reviewing the PDDRP, and also believe it is a concept that could be captured as part of implementation of the other rec about abusive sunrise registry practices

the pricing is protected by picket fence

it was discussed well in depth in our discussions

Agree - discussed that at length Maxim, no need to rehash that now

There was a new idea related to the TM-PDDRP in the public comments that we will be discussing in the coming days.

These are basically the same comments as before

an avenue to challenge pricing is not a new idea

Abuses by registries

it was discussed

using pricing, reservation of names, etc as a means of circumventing SUnrise

The reservation of Brands as premium names is most concerning.

That circumvents the RPM

The agreement of the WG, as staff understood, is that these examples will be incorporated in the implementation guidance language for Sunrise Rec 2

They’re public comments Maxim

You have re-stated our approach, yes

No second bite. Reserve list is not just about pricing. It's about unavailability. And there is a right to comment.

Sunrise Rec 2

public comments of the same group, which brought it here before

Implementation language for that will incorporate some of the examples provided in public comments of Sunrise Q2

Next meeting: The Review of all Rights Protection Mechanisms (RPMs) in all gTLDS PDP WG call is scheduled on Tuesday, 11 August 2020 at 13:00 UTC for 90 minutes.

please add my not about picket fence

Thanks everyone!

thanks all

Maxim staff did capture your picket fence comment

Thank you to staff for tracking this complex issue.

Bye all

Bye!

And thank to leadership for herding cats