[CWG-Stewardship] CCWG-ACCT Request for Guidance on PTI - IRP - Please respond by 23h59 UTC Monday 25 January 2016

Tue Jan 26 04:36:04 UTC 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 <cgomes at verisign.com> wrote:

> Thanks for responding Martin.  Please see my responses below.
>
>
>
> Chuck
>
>
>
> *From:* Martin Boyle [mailto:Martin.Boyle at nominet.uk]
> *Sent:* Monday, January 25, 2016 7:41 PM
> *To:* Gomes, Chuck; Matthew Shears; jrobinson at afilias.info;
> cwg-stewardship at icann.org
> *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:* cwg-stewardship-bounces at icann.org [
> mailto:cwg-stewardship-bounces at icann.org
> <cwg-stewardship-bounces at icann.org>] *On Behalf Of *Gomes, Chuck
> *Sent:* 25 January 2016 13:50
> *To:* Matthew Shears <mshears at cdt.org>; jrobinson at afilias.info;
> cwg-stewardship at icann.org
> *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:* cwg-stewardship-bounces at icann.org [
> mailto:cwg-stewardship-bounces at icann.org
> <cwg-stewardship-bounces at icann.org>] *On Behalf Of *Matthew Shears
> *Sent:* Monday, January 25, 2016 8:14 AM
> *To:* jrobinson at afilias.info; cwg-stewardship at icann.org
> *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:alice.jansen at icann.org
> <alice.jansen at icann.org>]
> *Sent:* 21 January 2016 17:05
> *To:* Lise Fuhr <Fuhr at etno.eu> <Fuhr at etno.eu>; Jonathan Robinson
> <jrobinson at afilias.info> <jrobinson at afilias.info>
> *Cc:* Mathieu Weill <mathieu.weill at afnic.fr> <mathieu.weill at afnic.fr>;
> Thomas Rickert <thomas at rickert.net> <thomas at rickert.net>; León Felipe
> Sánchez Ambía <leonfelipe at sanchez.mx> <leonfelipe at sanchez.mx>; Grace
> Abuhamad <grace.abuhamad at icann.org> <grace.abuhamad at icann.org>;
> acct-staff at icann.org
> *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
>
> CWG-Stewardship at icann.org
>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
> --
>
>
>
> Matthew Shears | Director, Global Internet Policy & Human Rights Project
>
> Center for Democracy & Technology | cdt.org
>
> E: mshears at cdt.org | T: +44.771.247.2987
>
>
>
> CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner.
>
>
> <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
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20160125/45b0818c/attachment-0001.html>