Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

PROPOSED AGENDA


 BACKGROUND DOCUMENTS



Info
titleRECORDINGS

Mp3

AC Recording

GNSO transcripts are located on the GNSO Calendar

...

Note

Notes/ Action Items


Actions:

ACTION ITEM: Row 3, 2.8.1.c.1, Comment #10, from the BC: Ask the BC why they request that if there are multiple IOs that one be from an emerging market.  Move BC comment to 2.8.1.e.7 on whether there should be more than 1 Independent Objector.

ACTION ITEM: Capture the text that we will be sending to the full WG.

ACTION ITEM: Change 20:00 UTC calls to 21:00 UTC.  Schedule a call for the week of 26 November.  There is no call next week.

 


Notes:

1. SOI Updates: No updates

2. 2.10.1 Base Registry Agreement - Continued

https://docs.google.com/spreadsheets/d/1MQmo1B6zBqGXYFRF2pKZXPhGmz0JfZhIaMxKIdVsT1g/edit#gid=1627799531 [docs.google.com] 


Row 15:  Should this Work Track recommend that ICANN include a covenant in the RA that the registry operator not engage in fraudulent and deceptive practices? Please explain.

-- 3 comments on this question.

-- All support/agreement.

-- Noting that they differ on how this should be implemented.

-- Anything that addresses existing contracts is probably out of scope (IPC and INTA comments).

-- May want to discuss whether we recommend to the full WG that this be a PIC or contractual. 

-- The concern that this is something ICANN legal should look at -- that there are no contractual provisions for Registry operators not to engage in fraudulent and deceptive practices.

-- We could leave it to ICANN and the associated Implementation Review Team.  But it may be more of a policy question -- an option for a third party to enforce (through a PIC).

-- Not sure this is the appropriate process to retroactively make changes to the registry agreements.

Jeff Neuman (Overall Co-chair): There is nothing preventing this group from expressing concern about how the agreement has been interpreted by the PICDRP and that is the reationale for our recommendation.  We can also state that comments have been provided that this PICDRD potentially got it wrong and asking ICANN to take a look at this.

Jeff Neuman (Overall Co-chair): That would not be outside of our group's scope since we are "reviewing" the program

Jeff Neuman (Overall Co-chair): We cant necessarily recommend the change, but we can point this out

 


Rows 19-33: Additional Comments:

Row 30, #11 - Premium Pricing for TLDs - Volker Greimann:

-- Highlights some of the issues on premium names.

-- What are we supposed to do with these comments?  This exercise is a way of demonstrating that as a WG we are taking due care and diligence on all comments that come in.  These should all be noted.  Not in our scope to deal with them, but suggesting to the full WG that we should mention in a cover note format/preamble that during our public comment a consider number of comments were received on this matter.

-- Annex of topics raised, considered but out of scope.

-- This comment (Volker's) falls in two areas: 1) putting something in the registry agreement for the registry to be more clear on pricing to its users; 2) fits into the registrar standardization topic.  Providing a standard way for registries to interact with registrars.

-- To the extent that this relates to the registry agreement, that is something we could recommend to the full WG, or we could view it as out of scope.

-- Needs more discussion outside of this Sub Group.

-- Don't agree that this is a policy issue -- it is a business practice experience.  Maybe a middle ground is that without recommendation or predjudice we bump it up to the WG. 


Row 33, #14 - CCT-RT:

-- This could be a recommendation to the GNSO for a completely new PDP.  Acknowledge it and say it is for the community to take up as a separate PDP.  This was also directed at the ICANN Board, RySG, RrSG, GNSO, SubPro. 

-- CCT-RT listed this as a prerequisite for any future gTLDs, so we should ask the full WG whether this should be a prerequisite.

Kristine Dorrain: There are provisions to address DNS Abuse in the RA.  If someone wants to double down and make them more draconian, then they need to request a PDP. 


3. 2.8.1 Objections:

https://docs.google.com/spreadsheets/d/1MQmo1B6zBqGXYFRF2pKZXPhGmz0JfZhIaMxKIdVsT1g/edit#gid=0 [docs.google.com]

Row 3, 2.8.1.c.1

-- BC - should be "agreement" with "new idea".

-- Why is BC, Comment #10, recommending an "independent objector" be included from an emerging market?  Should ask them this question.  But it is an "if there is" comment.  It's a nice to have that we can note, but probably won't make a difference on what we will be advising to the full WG.

ACTION ITEM: Ask BC why they suggested this; move BC comment to 2.8.1.e.7 on whether there should be more than 1 IO.

Steve Chan: Here is the question: 2.8.1.e.7: Role of the Independent Objector: In the 2012 round, there was only one Independent Objector appointed by ICANN. For future rounds, should there be additional Independent Objectors appointed? If so, how would such Independent Objectors divide up their work? Should it be by various subject matter experts?

Michael Casadevall: Basically its not a "New Idea", its more of an agree with saying how it should be implemented.

Kristine Dorrain: @Cheryl, as a new idea, doesn't it automatically go to the full group:?  More info from BC might help that full group discussion (or am I getting it wrong)??

Kristine Dorrain: @Cheryl agree with collecting

 


4. AOB:  Timing of the calls.  Change 20:00 UTC calls to 21:00 UTC.