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

26:44
Super helpful Mary. Thank you.

32:56
I think it's defined below.

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

34:37
Maybe say "and other indicators of source or quality"?

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

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

36:15
verbally and in the chat

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

38:34
My apologies for the disruption.

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

40:08
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.

40:19
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

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

41:08
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?

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

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

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

48:11
Agreed

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

49:30
hand up

49:36
over to Ariel

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

53:05
ok

53:32
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

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

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

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

58:16
@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.

58:38
+1 Susan

59:09
Need to keep Spec 13 exemption

01:00:30
Sorry to join late, had a conflicted call at 1 that just ended

01:00:35
sorry old hand

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

01:01:20
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

01:01:24
INTA does not feel strongly about it's recommendation.

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

01:04:28
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).

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

01:05:42
+1 Susan

01:06:16
Thanks David!

01:06:48
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)

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

01:07:17
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).

01:08:51
Thanks Mary

01:09:48
Spec 9 is the Registry Operator Code of Conduct

01:09:54
Spec 9 is a code of conduct as I recall, read it a while ago

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

01:10:21
And yes, it’s RO code of conduct.

01:10:45
new hand

01:10:49
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

01:10:58
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.”

01:11:59
What's the overlap of Spec 9 and Spec 13?

01:12:20
Spec. 9 examples are .catholic and .broadway

01:12:27
This seems beyond the scope of what we've discussed in the past.

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

01:13:16
.med

01:13:18
.living

01:13:47
.helsinki

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

01:13:58
new hand

01:15:10
This is not new.

01:15:46
Agree. Not new.

01:15:50
Part of the RA

01:16:18
We have not clear definition of this small, odd group.

01:16:26
no clear definition

01:16:34
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.

01:16:57
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

01:17:39
+1 Susan - public comment needs to be a meaningful exercise.

01:17:58
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

01:18:03
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

01:18:44
@David, for sure.

01:20:21
", unless otherwise exempted."

01:21:00
Let's include more background material when this comes back to the WG

01:21:14
everyone should understand it fully when it comes back

01:22:04
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

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

01:24:51
(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.

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

01:34:00
We will

01:35:20
@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.

01:40:13
Row 22-23

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

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

01:40:58
@Griffin, yes I think that’s right.

01:41:09
(Abusive practices by ROs that is)

01:41:27
I think the IPC comments are in a similar vein as well

01:41:44
Agree nothing new here, think we move on

01:44:28
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

01:45:04
the pricing is protected by picket fence

01:45:21
it was discussed well in depth in our discussions

01:45:33
Agree - discussed that at length Maxim, no need to rehash that now

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

01:46:21
These are basically the same comments as before

01:46:30
an avenue to challenge pricing is not a new idea

01:46:33
Abuses by registries

01:46:34
it was discussed

01:46:42
using pricing, reservation of names, etc as a means of circumventing SUnrise

01:47:20
The reservation of Brands as premium names is most concerning.

01:47:28
That circumvents the RPM

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

01:48:05
They’re public comments Maxim

01:48:21
You have re-stated our approach, yes

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

01:49:58
Sunrise Rec 2

01:50:13
public comments of the same group, which brought it here before

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

01:50:21
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.

01:50:34
please add my not about picket fence

01:50:38
Thanks everyone!

01:50:46
thanks all

01:50:50
Maxim staff did capture your picket fence comment

01:50:57
Thank you to staff for tracking this complex issue.

01:50:58
Bye all

01:51:40
Bye!

01:51:44
And thank to leadership for herding cats