Subject: Re: [CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016
From: Martin Boyle <[email-masked]>
To: Greg Shatan <[email-masked]>, "Gomes, Chuck" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2016 15:16:36 +0000

Thanks both:  very helpful.  May I summarise for the different cases Chuck helpfully identified?

1.       A gTLD is not delegated as requested by a registry operator without appropriate justification:  I think that we all agree that the gTLD registry request for a delegation is an issue directly within ICANN’s responsibility and so action (IRP) would be correctly with ICANN for any failure to meet bylaws.  There might be a case where ICANN had requested PTI to take action, but that PTI failed to carry out.  A bylaw obligation on ICANN to enforce its contract with the IANA functions operator would seem appropriate here, and would probably be more appropriate than escalation via the CSC.  There may be cases where it would be considered better to escalate via the CSC (there was some structural problem, for example).  In this case the “end of the line” would be via the RySG and/or ccNSO leading to a decision to carry out a special IFR.

2.       Modification to a zone file record for a gTLD [or ccTLD] is not made without proper justification:   I’m not sure I’d agree with Greg on using the IRP against PTI.  We already have two options:  requiring ICANN to enforce its contract or escalation via CSC.  Given that there has not been “proper justification” the former would seem to me to be most appropriate.  If there is doubt on policy grounds, the CSC might be better as that could ask the GNSO [or ccNSO] to sort.  I agree with Greg that taking an isolated incident to an IFR could appear to be overkill (although refusal to correct without explanation would seem to me to be pretty serious!), but in this case the IRP route would seem to me to be relevant.

3.       SLEs are not met after applicable procedures are followed:  escalation via CSC and through an IFR (although I would expect ICANN to be actively working with its affiliate to correct the deficiency).  In the discussions in DT-C, we did note that there might be work between CSC and PTI (or successor) to identify why SLEs had not been met and how to address this – it might be that an SLE was too onerous or perhaps not a relevant measure, in which case there might need to be further consideration of the setting.  It might be that additional resources are needed, in which case serious consideration needs to be given to remedial action.  I noted that there could be another issue – that PTI was trying to force additional requirements on the registry (membership of the ccNSO, signing a contract…) that were not agreed policy:  in this case (which might also apply to 2. above), the IRP is the right approach.

So summarising my summary, the two options are sufficient:

i.                     A bylaw obliging ICANN to enforce its contract with the IANA functions operator (and an IRP is available if it should not do this)

ii.                   Issues where PTI is ignoring agreed policy or making up its own can be addressed via the IRP with ICANN or via the ICANN bylaw to enforce its contract

iii.                  Performance issues can be addressed via the CSC (systemic) or via an IRP (isolated incident)

Is that right?

Martin

From: Greg Shatan [mailto:[email-masked]]
Sent: 26 January 2016 04:36
To: Gomes, Chuck <[email-masked]>
Cc: Martin Boyle <[email-masked]>; Matthew Shears <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016

Martin and Chuck,

Please allow me to add my 2 cents below.

Greg

On Mon, Jan 25, 2016 at 8:03 PM, Gomes, Chuck <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for responding Martin.  Please see my responses below.
 Chuck
 From: Martin Boyle [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 25, 2016 7:41 PM
To: Gomes, Chuck; Matthew Shears; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016
 For the gTLDs, I’m afraid I still do not properly understand where fundamental authority lies, so please bear with me chuck:  I’ll get there one day…
 On 1, the {putative] registry operator requests a delegation.  I assume that it would be for ICANN to agree to grant and to show this by signing a contract.  If it refused to for reasons that failed the “bylaw test,” an IRP against ICANN would seem to be appropriate.  But there might be other reasons – community objections, or GAC opposition or even failure to meet the criteria.  So wouldn’t “might be applicable” be correct here?
[Chuck Gomes] It depends.  Are the community objections or GAC opposition in line with approved policy?  For a registry appeal to be effective, it should be based on approved policy.  And community objections or GAC opposition should also be consistent with approved policy.
 ​This does not seem like a "PTI" issue.  Rather this is an ICANN issue.  So it is not really relevant to this question (although it's an interesting question).  Now if ICANN approved the application and entered into a registry agreement, but PTI refused to delegate, then it would be a PTI problem, and the applicant could try to resolve this through CSC or through ICANN's enforcement of its contract with PTI.  If CSC does not succeed, what is the end of the line for resolving a performance problem?  Is it an IRP, and is the other party in the IRP PTI or ICANN?
On 2:  I guess this would be the same for a ccTLD as for a gTLD.  This would appear to fail PTI (or future IANA functions operator) obligations to ICANN under its contract.  I think I’m with Becky on this:  a bylaw requirement on ICANN to enforce its contract with PTI would seem to be the simplest approach and an IRP could then challenge ICANN for failure.  But is there a more direct approach here:  this would appear to be likely to fail one or more of the SLEs.  It should be reported to the CSC, which (if there is refusal to correct) would escalate to RySG and/or ccNSO which would then decide on further action (a special IFR which could then lead to a RfP).  I have a certain antipathy to parallel paths and would certainly prefer the more “resolution-based” CSC to the more legalistic IRP.
[Chuck Gomes] No argument here.
​As with the above issue, if CSC cannot resolve the issue, the next step after that should be an IRP (but not based on ICANN violating a bylaw; rather it should be based on PTI's failure to do what is required of it).  A special IFR (and possibly an RfP) based on a single failure to delegate seems like overkill to me.  I do agree that the IRP should not be invoked until the CSC route has run its course.
And, in the case of ccTLDs, judging whether there is justification to reject (or simply delay) might be difficult.
For 3:  this would seem to me to be a CSC issue – that’s what they are there for, complete with their own processes to resolve the problem.  I guess that an obligation to enforce the contract would make it easier for the CSC to guarantee access to ICANN should PTI remain obdurate (and that might be particularly relevant in a post PTI world, should ICANN have to rebid the contract).
[Chuck Gomes] What if CSC cannot resolve the problem?
For me the fundamental reason why we might want to invoke an IRP would be that PTI is ignoring agreed policy (or seeking to impose its own ideas, as ICANN did in the early days).
[Chuck Gomes] Agreed.
Imagine PTI decides it wants to impose a contract on all its “customers” (where few ccTLDs have contracts and where (if I understand right) gTLDs have their authority from the contract they sign with ICANN.  That TLDs denied service unless they accept a condition that is not in policy (and therefore should be in breach of its contract with ICANN) should have the right to appeal through the IRP would seem to me to be reasonable use of an IRP.  Hanging around waiting for the ccNSO & GNSO to initiate a special IFR and then trigger remedial action and/or separation for an attempt at extension of power by PTI would seem to me possible, but not optimum.
[Chuck Gomes] Agreed again.
Happy to hear thoughts.
Martin
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gomes, Chuck
Sent: 25 January 2016 13:50
To: Matthew Shears <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016
Let me give a few examples where I think that the IRP would be applicable:

1.       A gTLD is not delegated as requested by a registry operator without appropriate justification.

2.       Modification to a zone file record for a gTLD is not made without proper justification.

3.       SLEs are not met after applicable procedures are followed.

I think that we have recommended processes that would hopefully solve problems like the above well before an IRP would be needed, but it those processes do not work in a timely manner, then an IRP would provide an objective and well-defined option for an appeal.  I think the affected registry operator, the RySG or the GNSO should all have standing to use the IRP in cases like the above if needed.  The RySG in its comments over the history of the CWG Stewardship has repeatedly emphasized the need for registry operators to be able to appeal IANA decisions that they believe are contrary to policy.

I suspect that others could come up with other examples.

Chuck

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Matthew Shears
Sent: Monday, January 25, 2016 8:14 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016

Would it be useful to try and list the possible situations where recourse to an appeals mechanism would be used?  This might give us a better sense of what type of mechanism would be suited and whether or not the IRP would be appropriate/adequate?

Matthew
On 22/01/2016 12:33, Jonathan Robinson wrote:
All,

We have received a direct request (see below) from the CCWG Accountability Co-Chairs for further guidance with respect to the application of the IRP to the actions (or inactions) of PTI.

Moreover, we have had input from Sidley via the Client Committee as follows:

“Sidley spoke with Becky Burr from CCWG today regarding the CWG dependency for an IRP process.   Based on the call, it appears that the open question for CWG is whether the CWG dependency is adequately met with an ICANN bylaw provision that allows for an IRP if ICANN fails to enforce the contract with PTI (for example, due to a material performance breach by PTI that is not cured)  – or whether in addition to such an ICANN bylaw, a separate process is also required that would give direct customers a right to mediation or arbitration to address SLAs or other service issues.   If the latter is required, then in order for CCWG to create such a process, it would need input from CWG on what the standard of review should be for those types of proceedings and what the type of process would be – for example, would non-binding mediation be sufficient to address a direct customer issue or would binding arbitration be required?   By clarifying this point, CCWG will be better positioned to ensure that the CWG dependency is being met in the CCWG proposal.”

So the essential question is:

A.     Is an ICANN bylaw provision that allows for an IRP if ICANN fails to enforce the contract with PTI (for example, due to a material performance breach by PTI that is not cured) sufficient?

OR

B.     In addition to such an ICANN bylaw, is a separate process also required that would give direct customers a right to mediation or arbitration to address SLAs or other service issues?

If B above, what type of process is necessary?

As discussed in our CWG meeting yesterday, it will be particularly helpful if when responding to the above, you provide a rationale for your response.
In addition, if possible, please make reference to (and be consistent with) the prior work of this CWG Stewardship (such as our proposal in response to the RFP from the ICG).

Given that the request from the CCWG Co-Chairs indicates their need to close this item by 28 January, we need to discuss this soon. Accordingly, we request that you provide input ASAP and, in any event, by 23h59 UTC Monday 25 January 2016.

Thank-you,

Jonathan & Lise
Co-chairs, CWG Stewardship

From: Alice Jansen [mailto:[email-masked]]
Sent: 21 January 2016 17:05
To: Lise Fuhr <[email-masked]><mailto:[email-masked]>; Jonathan Robinson <[email-masked]><mailto:[email-masked]>
Cc: Mathieu Weill <[email-masked]><mailto:[email-masked]>; Thomas Rickert <[email-masked]><mailto:[email-masked]>; León Felipe Sánchez Ambía <[email-masked]><mailto:[email-masked]>; Grace Abuhamad <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: CCWG-ACCT Request for Guidance on PTI - IRP

Sent on behalf of CCWG-Accountability Co-Chairs

Dear Lise, Dear Jonathan,
This is to inform you that further to our call #79, the CCWG-ACCT seeks the CWG-Stewardship’s guidance on the two proposed approaches that were suggested to address the dependency that relates to PTI compliance through the Independent Review Process (IRP) i.e.:
1.      Provide direct access to IRP for PTI action or inaction;
2.      Oblige ICANN in Bylaws to ensure PTI compliance, in which case failure to do is covered by IRP.
We are currently in the final stages of discussion to issue our supplemental report and would need to close this item by 28 January. Any prompt feedback you could send us would be much appreciated.
We look forward to your guidance.
Thank you
Best regards
Mathieu, Thomas, León

_______________________________________________

CWG-Stewardship mailing list

[email-masked]<mailto:[email-masked]>

https://mm.icann.org/mailman/listinfo/cwg-stewardship

--

Matthew Shears | Director, Global Internet Policy & Human Rights Project

Center for Democracy & Technology | cdt.org<http://cdt.org>

E: [email-masked]<mailto:[email-masked]> | T: +44.771.247.2987<tel:%2B44.771.247.2987>

CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner<http://cdt.org/annual-dinner>.
[https://ipmcdn.avast.com/images/logo-avast-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

This email has been sent from a virus-free computer protected by Avast.
www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

_______________________________________________
CWG-Stewardship mailing list
[email-masked]<mailto:[email-masked]>
https://mm.icann.org/mailman/listinfo/cwg-stewardship