051040040 RPMs in all gTLDS PDP WG - Shared screen with speaker view
the first one
the one that said no password required.
Ditto for Subpro last night.
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en.
Both times stopped until password provided.
Thank you David!
Good day to all
@kathy have you updated Zoom recently?
Version 5.4.2 is the most recent.
@Nathalie -- that may be it! I'll give it a shot...
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.
I think that kind of light touch clarification makes sense
@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
Thanks Phil. Makes sense
Good to have this background. Tx Julie.
Agree -- thx David
Is it just me or is David’s audio fading in and out
David's audio seems to be fading in and out ...
sound is coming and going here too
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.
The Working Group generally agreed that some Registry Sunrise or Premium Name 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.
The context was included in the context
If I recall
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
It was not intended to be an RA provision in itself
Correct, Griffin - the contextual language is included in the context section in the initial report, right below the recommendation
@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.
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.
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
But is this our role? Or is this the role of the full WG?
Michael + 1 PICs circumvent RPMs for example
@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
Agree with Paul — The issue at this point is not whether the language should c
be revised, but how it should be revised for clarity.
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."\
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?
+1 Phil. Let's take it back to the full WG.
I haven’t heard anyone say to throw out the Rec
Why don't we figure out a clarified recommendation? Agree with Brian
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.
Is there a reason not to recommend "imprevements" here
Perhaps a small team here to suggest some clarifying language.
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.
I like that idea John - small team to work it out
Agree with John -- to suggest clarifying language
Agree with David.
Put down my hand
Agreee with David and John
Interesting to see on the screen that "ICANN org does not foresee any issues..."
@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.
I’m confused as to how a recommendation stating that the status quo is maintained can be construed as too broad or vague?
Agree with @Griffin
Anything would be considered too broad or vague if you ignore all the contextual background
can't hear Susan
Can't hear Susan
32% support; 31% significant change; do not support
@Susan: Correct, the context explains the concept of the challenge mechanism
Completely agree Susan
We have included contextual language on the wiki page where the recommendation is posted
Unfortunately I think requiring commenters to take the extra step of following a link to find the context simply prevented many from doing so
Agree with Susan — “Too broad/vague” here means they apparently did not understand proposal. Also — “non support” is not clearly supported in the comments.
David: put to the same small group?
David McAuley (Verisign)
don' think 31% sig change is right Kathy
If we want to encourage proper consumption of the report we may need to have all the context just there with the rec
@Susan, I empathize but we have what we have, so what do we do?
@David - very concerned that everything will be put to a "small group" as Kathy suggests. Now we have a Sub Sub Group making decisions.
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)
@Phil — Isn’t the implementation process here to do nothing?
Sorry David, I meant 31% (30.9) significant change + do not support
Agree with Paul - we cannot send everything where commuters simply refused to take into consideration full context to mean that a rec is unclear
+1 Phil on implementation as a serious concern
Only limited to specific cases where reasonable clarifications to a rec are warranted
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.
@Brian +1 — Since no agreement, no change.
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
The biggest response was no response or opinion - 60%
(I hear birds ; )
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
IPC suggestion does seem new
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?
It is a new idea
That I don’t believe had been discussed by the WG
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
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
Susan I am supporting it’s consideration!
I support this being flagged for WG consideration
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".
I imagine that would be up to each RO.
David McAuley (Verisign)
Kathy old hand?
@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.
It would not show DN as registered?
let's give this background to full WG - tx!
Let's take yes for an answer ;-)
@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?
Agree with Michael G
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
I wouldn’t mind flagging this suggestion, but not super strongly
early is great!
In the contextual language of Rec 5, there is a note that “most Registry Operators have run the End Date Sunrise”
+1 Kathy, I thought we discussed this
@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.
I would support staff double checking to see about whether this was discussed before
@Roger and Kathy -I'm happy if we did discuss - I just couldn't remember and it seemed the only possible "new issue"
Thanks to everyone/good progress