
17:52
the first one

18:00
the one that said no password required.

18:08
Ditto for Subpro last night.

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

18:18
Both times stopped until password provided.

18:20
Thank you David!

18:23
Good day to all

18:28
@kathy have you updated Zoom recently?

18:54
Version 5.4.2 is the most recent.

19:13
@Nathalie -- that may be it! I'll give it a shot...

19:19
Sorry 5.0.4

20:21
https://docs.google.com/spreadsheets/d/1xMehg9o44bdz85ry0LJvhzoOaKdmJ6SwIrLneMx0Ixc/edit#gid=1163822586

20:58
Is it our task to decide what recommendations move on the the full WG as David mentioned, or is it to go through the public comments and see if there was anything new from them that the full WG needs to decide? If the former, I think we have changed our scope significantly during this past week.

22:41
I think that kind of light touch clarification makes sense

23:48
Thanks David.

24:10
@Paul--personal view, I think it's the reverse -- first see if new ideas or facts suggest the recommendation should be changed, or indicate that the community strongly favors or disfavors, and then send on to full WG with any modifications as well as a reading on where the community is at

24:46
Thanks Phil. Makes sense

29:06
Good to have this background. Tx Julie.

33:25
Tx David!

33:42
Agree -- thx David

35:17
Is it just me or is David’s audio fading in and out

35:23
Fading

35:24
David's audio seems to be fading in and out ...

35:32
sound is coming and going here too

35:39
Fine with moving on. Again, I believe that in our Final Report we should have some language that the required RPMs do not prevent any registry operator from offering additional RPMs. I believe that reflects our actions as a WG and our consideration of private RPMs like DPML.

38:53
The Working Group generally agreed that some Registry Sunrise or Premium Name[1] pricing practices have limited the ability of some trademark owners to participate during Sunrise. The Working Group is aware of cases where the Registry Operator practices may have unfairly limited the ability of some trademark owners to participate during Sunrise, when pricing set for the trademark owners was significantly higher than other Sunrise pricing or General Availability pricing. The Working Group noted that this problem seems sufficiently extensive that it requires a recommendation to address it.

39:32
The context was included in the context

39:37
If I recall

40:34
Also - as noted last time, I think we were in agreement that this policy recommendation would require more concrete language for purposes of implementation of an actual RA amendment

40:47
It was not intended to be an RA provision in itself

41:19
Correct, Griffin - the contextual language is included in the context section in the initial report, right below the recommendation

42:09
@Griffin, yes it was in the report. If it helps, I can confirm that, during implementation, ICANN org and the IRT look at the entire report to obtain guidance and clarity if needed, not just the rec itself.

44:53
Also, as mentioned last week, we do not require or request that a PDP WG actually draft contractual text. Implementation guidance can be in the form of examples that the WG considered, for instance.

47:26
Clarification - The colored content in the “Sub Group Response” column is just tag, in case you scroll through the tab and get lost where you are

48:10
But is this our role? Or is this the role of the full WG?

48:22
Michael + 1 PICs circumvent RPMs for example

48:33
@Kathy, as I said I don't dispute that additional implementation guidance may be beneficial here. I was trying to understand what the future status of the context text is, since this is relevant to every recommendation

49:44
Agree with Paul — The issue at this point is not whether the language should c

50:17
be revised, but how it should be revised for clarity.

51:56
This should not be hard to provide a bit more detail on this concept. I note the RA in Spec 11 uses broad prohibitions such as "Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies."\

52:04
+1 John

52:14
+1 John

52:36
+1 John

52:56
+1 John

53:25
I think Phil is right… why don’t we flag this Rec, take back to full WG, and work on a more fully fleshed out iteration of the text?

53:43
+1 Phil. Let's take it back to the full WG.

54:40
I haven’t heard anyone say to throw out the Rec

54:46
Why don't we figure out a clarified recommendation? Agree with Brian

54:59
Thank you Griffin & Paul. I'd encourage members to work on clarifying language and have that ready for when the full WG takes it up.

55:25
Is there a reason not to recommend "imprevements" here

55:28
Perhaps a small team here to suggest some clarifying language.

55:33
For our work — I do think we need to determine whatt he “Sub Group Response” should be for each proposal and insert those for approval.

55:35
+1 John

55:55
I like that idea John - small team to work it out

56:03
Agree with John -- to suggest clarifying language

58:57
Agree with David.

59:05
Put down my hand

59:21
Agreee with David and John

01:01:04
Interesting to see on the screen that "ICANN org does not foresee any issues..."

01:01:59
@Brian, yes - to us, the recommendation text was clear. As I mentioned, the concern was to make sure that implementing it will accurately reflect the intended scope and be consistent with the rest of the RA.

01:03:12
I’m confused as to how a recommendation stating that the status quo is maintained can be construed as too broad or vague?

01:03:58
Agree with @Griffin

01:04:05
Anything would be considered too broad or vague if you ignore all the contextual background

01:04:15
can't hear Susan

01:04:18
Can't hear Susan

01:04:50
32% support; 31% significant change; do not support

01:05:28
@Susan: Correct, the context explains the concept of the challenge mechanism

01:05:37
Completely agree Susan

01:05:53
Susan +100

01:06:07
We have included contextual language on the wiki page where the recommendation is posted

01:06:32
Unfortunately I think requiring commenters to take the extra step of following a link to find the context simply prevented many from doing so

01:06:32
Agree with Susan — “Too broad/vague” here means they apparently did not understand proposal. Also — “non support” is not clearly supported in the comments.

01:06:40
David: put to the same small group?

01:06:49
don' think 31% sig change is right Kathy

01:06:52
If we want to encourage proper consumption of the report we may need to have all the context just there with the rec

01:06:53
@Susan, I empathize but we have what we have, so what do we do?

01:07:20
@David - very concerned that everything will be put to a "small group" as Kathy suggests. Now we have a Sub Sub Group making decisions.

01:07:30
This is the wiki page set up for Sunrise Recommendation 2, which is linked in the Google Form where people are asked to provide comments for Rec 2: https://community.icann.org/display/RARPMRIAGPWG/Sunrise+Recommendation+%232 (context right below the recommendation)

01:07:35
@Phil — Isn’t the implementation process here to do nothing?

01:07:41
Sorry David, I meant 31% (30.9) significant change + do not support

01:07:42
Agree with Paul - we cannot send everything where commuters simply refused to take into consideration full context to mean that a rec is unclear

01:07:55
+1 Phil on implementation as a serious concern

01:08:02
Only limited to specific cases where reasonable clarifications to a rec are warranted

01:08:30
This is the problem with us not sticking to our remit. We will never ever get through these if everything has to go through a Sub Sub Group, then a Sub Group, then the full WG. Let's cut out the 2 middlemen and do what we were told we would be doing.

01:09:23
@Brian +1 — Since no agreement, no change.

01:09:25
I think Brian is right… we believe there should be a uniform challenge mechanism but recognize there is not consensus so I think the recommendation of status quo must remain

01:10:15
Agree David

01:10:20
Griffin +1

01:11:17
The biggest response was no response or opinion - 60%

01:12:09
(I hear birds ; )

01:12:32
It seems to me the problem with placing too much weight on the pie charts is an inherent bias through the difference between bulk support v broad support

01:13:17
IPC suggestion does seem new

01:13:23
Question: I believe that our remit does include that we should provide response to each comment — some confirmation that we have reviewed the comment and decided X because of Y. These should be prepared for approval by the subgroup — OR are we going to wait and have the Full PDP prepare these responses?

01:14:56
It is a new idea

01:15:04
That I don’t believe had been discussed by the WG

01:15:30
well I think it's our job in this Sub to consider new ideas isn't it? That's what we were told we were here for

01:15:36
It is a solution to an issue that has been identified, without going so far as to require publication of an ROs reserved names list, which also carries its own set of concerns

01:16:02
Susan I am supporting it’s consideration!

01:16:05
*its

01:16:47
Yes,

01:16:48
Support consideration

01:16:49
I support this being flagged for WG consideration

01:16:52
Yes

01:18:01
My experience has been when you try to register a domain name that has been reserved you get a generic message that "name is not available".

01:18:12
I imagine that would be up to each RO.

01:18:34
Kathy old hand?

01:18:39
@MichaelG - FYI, a PDP WG isn’t required to prepare a response to each and every comment. What it is required to do is to make sure that the comments were considered - practically speaking, this is normally done through a combination of the Public Comment Review Tool, WG discussions of the Tool (including sub groups), and the recordings and transcripts. In the Final Report, the text normally points to these meetings and documents so that a reader can ensure all comments were compiled and had ample opportunity to be considered and discussed.

01:19:00
It would not show DN as registered?

01:21:05
let's give this background to full WG - tx!

01:22:31
Let's take yes for an answer ;-)

01:23:15
@Mary — Sensible,but I wonder if in light of the importance of the Final Report we will be preparing and the likelihood that some commenters whose suggestions are not accepted may raise this as a last minute issue, I would think a “Considered but not adopted” or “Considered, but thoroughly discussed in ____ stage and not adopted.” etc. would be useful. Referring questioners to “the record” is not generally helpful. Without noting our consideration and decisions here, how do we report our considerations to the full WG, much less GNSO?

01:23:58
Agree with Michael G

01:24:30
Michael - the final report contextual language for each final recommendation should include the high-level summary of how the Sub Group/WG deliberated on the public comments

01:24:34
ok

01:24:37
I wouldn’t mind flagging this suggestion, but not super strongly

01:24:48
early is great!

01:24:50
Tx David

01:26:40
In the contextual language of Rec 5, there is a note that “most Registry Operators have run the End Date Sunrise”

01:27:15
+1 Kathy, I thought we discussed this

01:27:22
@Ariel — This process was developed with the express purpose of ensuring and confirming review of all comments. Similar comments can be responded to with the same answers, but alls should be answered. I’m not suggesting more work or analysis, but being responsive to the community — particularly in the context of these reviews.

01:27:46
I would support staff double checking to see about whether this was discussed before

01:29:28
@Roger and Kathy -I'm happy if we did discuss - I just couldn't remember and it seemed the only possible "new issue"

01:29:34
Thanks to everyone/good progress