[Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 2 October 2018 at 03:00 UTC

[Rubens Kuhl]

> On 3 Oct 2018, at 15:26, Aikman-Scalese, Anne <AAikman at lrrc.com <mailto:AAikman at lrrc.com>> wrote:
> 
> Rubens – so can you clear this up for me?
>  
> Are you saying that a Review Team can make a Recommendation to the Board and the GNSO that would require adoption of a Consensus Policy,

No RT recommendation would require anything. They are recommendations, not binding orders. 
But if an RT makes a recommendation to the Board, and the Board accepts it (as in truly accepting it, since some acceptances of the last few years have been refusals dressed as acceptance), the Board can initiate a PDP. Alternatively, GNSO might find that recommendation in order and ask for an Issue Report to start a PDP, or start an ePDP directly from the recommendation if the RT output was of enough density to preclude the need for an Issue Report. 
In any case, that PDP is what could end in a Consensus Policy, even though it could be tracked to advice originating from an RT. 


> but that a regular old PDP like Subsequent Procedures cannot address an issue or make a recommendation that would require adoption of Consensus Policy?

Not all PDPs are made equal, and Subsequent Procedures has only one issue where it might create a Consensus Policy, in regard to  name collisions in legacy gTLDs.
It all goes down to charter and the issues mentioned in the charter. 


Rubens





> Thank you,
> Anne
>  
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 <tel:520.629.4428> office
> 520.879.4725 <tel:520.879.4725> fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _____________________________
> <image003.png>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 2000
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
>  
>  
> From: Rubens Kuhl [mailto:rubensk at nic.br <mailto:rubensk at nic.br>] 
> Sent: Tuesday, October 02, 2018 3:37 PM
> To: Aikman-Scalese, Anne
> Cc: Steve Chan; gnso-newgtld-wg at icann.org <mailto:gnso-newgtld-wg at icann.org>
> Subject: Re: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 2 October 2018 at 03:00 UTC
>  
>  
> 
> 
> On 2 Oct 2018, at 16:00, Aikman-Scalese, Anne <AAikman at lrrc.com <mailto:AAikman at lrrc.com>> wrote:
>  
> Hi Rubens,
> I think Jeff clarified yesterday that the Review Recommendations are in fact recommendations to the Board – in the sense that the Board, as the final arbiter, as to deal with these in some manner.  It seems that in the draft, we are taking the position that this PDP can certainly question, reexamine, and disagree with those Recommendations and that some of them relate to matters of contract between the Contracted Parties and ICANN org.  You state that these matters are “inside the picket fence” and thus out of scope for the PDP.
>  
> Actually, what I said to be inside the picket fence is what can be analysed by PDPs, and what can't be, is what I said to be outside. And it's not just for the PDP, but for all PDPs. It's a contractual assurance ICANN gave to contracted parties so they can accept the "blank check" parts which allow consensus policies. 
>  
> 
> 
>  
> I would note two things:
>  
> I.                    When there is disagreement between two bodies giving policy advice to the ICANN Board, the Board often seems to come back and request a “work-out”.  I think that is why Jeff and Cheryl seemed to agree yesterday on the call that our guidance on treatment of the CCT-RT Review Recommendations has to come from the GNSO Council.   As we know, these processes can be time-consuming.  So I think we all need to think about how to “cut to the chase”.  Unless these differences are addressed correctly from a procedural standpoint, there will be a bottleneck to launching the next round.  I am not sure our Charter is crystal clear on this point.  See reference to CCT-RT work from the final Charter pasted below:
>  
>  
> A work-out is only possible within standing SOs and ACs. CCT-RT is a time-limited endeavour that ends with their published report, and there is no procedural standpoint to be a basis for. 
> 
> 
> <image003.png>
>  
> II.                  Regarding the “picket fence”, it strikes me there are a number of items being considered in the Sub Pro PDP that might require changes to the RA and RAA, including changes that are desired by the Contracted Parties.  Should this PDP be doing an “audit” in this regard as to which policy changes might affect the Contracts?  As I understand it, the rule for a GNSO PDP is that the RA and RAA may only be affected by Consensus Policy recommended by the GNSO and adopted by the Board.  I do not understand the scope of the PDP to EXCLUDE entirely every topic that would result in a change to the standard RA or RAA.  Excerpts from the Charter relative to contracts appear below:
>  
> SubPro PDP does not intend to produce a Consensus Policy (capital C, capital P), but a GNSO Policy. This allows for greater latitude in what it can specify. I mentioned CPs because what CCT-RT suggested in those 2 recommendations meant to be applicable to all gTLDs, not only gTLDs yet to be applied for, and then they need to be within the Consensus Policy boundaries. 
>  
>  
> Rubens
>  
> 
> 
> This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521 <tel:2510-2521>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20181003/6c4688ec/attachment-0001.html>