[client com] FW: [CCWG-ACCT] PTI and the IRP

Thu Jan 21 02:59:06 UTC 2016

My initial concern with the highlighted language is whether "material
breach by PTI" is consistent with the standard by which PTI
actions/inactions are to be judged up to that point.  If there are
complaints about PTI actions/inactions that remain unresolved but don't
rise to the level of a material breach, then an IRP based on the above
standard would be unavailable to resolve those concerns.

Greg

On Wed, Jan 20, 2016 at 9:07 PM, Flanagan, Sharon <sflanagan at sidley.com>
wrote:

> Dear Client Committee,
>
>
>
> We wanted to flag for you a recent discussion on the CCWG list serve
> relating to the CWG requirement for an IRP process to cover PTI
> actions/inactions.   The email chain is pasted below and includes input
> from Greg and Avri.
>
>
>
> Also, below is the language from the final CWG comment letter to CCWG on
> this point. We believe the approach highlighted in yellow could be a
> workable solution.
>
>
>
> *“As we noted in our comment letter to the Second Draft Proposal, the
> Third Draft Proposal does not explicitly address the CWG-Stewardship
> requirement that an independent review process be available for claims
> relating to actions or inactions of PTI. This requirement could be
> addressed in a number of ways. For example, a provision could be added to
> the ICANN Bylaws that would require ICANN to enforce its rights under the
> ICANN-PTI Contract/Statement of Work (SOW), with a failure by ICANN to
> address a material breach by PTI under the contract being grounds for an
> IRP process by the Empowered Community (after engagement and escalation).
> Another approach would be to expand and modify, as appropriate, the IRP
> process currently contemplated by the Third Draft Proposal to cover claims
> relating to actions or inactions of PTI, with the ICANN Bylaws and PTI
> governance documents expressly confirming that the IRP process is binding
> on PTI (which provisions would be Fundamental Bylaws that could not be
> amended without community approval). Regardless of approach, the
> CWG-Stewardship requires that this dependency be addressed in the final
> CCWG-Accountability proposal in order for the CWG-Stewardship to confirm
> that the conditions of the CWG-Stewardship final transition proposal have
> been adequately addressed.”*
>
>
>
> As counsel to CCWG, we have a call with Becky Burr  from CCWG on this
> topic tomorrow.    If there is any additional guidance that CWG would like
> to provide on this topic beyond what was included in the comment letter,
> could you please let us know?
>
>
>
> Best regards,
>
> Holly and Sharon
>
>
>
> *SHARON* *FLANAGAN*
> Partner
>
> *Sidley Austin LLP*
> +1 415 772 1271
> sflanagan at sidley.com
>
>
>
>
> ------------------------------
>
> *From:* accountability-cross-community-bounces at icann.orgOn Behalf OfBurr,
> Becky
> *Sent:* Wednesday, January 20, 2016 11:42:41 AM (UTC-08:00) Pacific Time
> (US & Canada)
> *To:* Schaefer, Brett; Greg Shatan; Avri Doria
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] PTI and the IRP
>
> I am willing to address this issue either way here.  We just need
> clarification from the CWG as to its preference.  Either we create a
> stand-alone standard of review (in which case I need help articulating) or
> we say (in the Bylaws) that ICANN is responsible for ensuring that PTI gets
> it right, and allow challenges via the IRP on the basis of ICANN’s actions
> or inactions that fall below this standard.
>
>
>
> *J. Beckwith Burr*
> *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer
> 1775 Pennsylvania Avenue NW, Washington D.C. 20006
> *Office:* +1.202.533.2932  *Mobile:* +1.202.352.6367 */* *neustar.biz*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.neustar.biz&d=CwMF-g&c=Od00qP2XTg0tXf_H69-T2w&r=AKn_gzAS4ANpCEqx2GjPwjUkqYPHaN7m0NQNyfQXAgk&m=1xdOjghwOaRYcxDPTuhZkMCTD7eRwKXzUuTnQOV8IMo&s=xy01Bx-Fh__bSI6ZDFiOqvA0_GlpT0jRy5DUdZh1uvw&e=>
>
>
>
> *From: *<Schaefer>, Brett <Brett.Schaefer at heritage.org>
> *Date: *Wednesday, January 20, 2016 at 10:45 AM
> *To: *Greg Shatan <gregshatanipc at gmail.com>, Avri Doria <avri at acm.org>
> *Cc: *Accountability Community <accountability-cross-community at icann.org>
> *Subject: *Re: [CCWG-ACCT] PTI and the IRP
>
>
>
> I agree and would add that DIDP appeals, although they potentially could
> involve a bylaws violation I suppose, would most often involve an
> independent review via IRP of the original decision to ensure that it was
> correct.
>
>
>
> It seems that the IRP is being stretched in the borrowing. At the very
> least, there needs to be clarification that on how the IRP should handle
> these matters if it is the proper vehicle and, if it is not, what exactly
> should be created to handle these matters.
>
>
>
> *From:* accountability-cross-community-bounces at icann.org [
> mailto:accountability-cross-community-bounces at icann.org
> <accountability-cross-community-bounces at icann.org>] *On Behalf Of *Greg
> Shatan
> *Sent:* Wednesday, January 20, 2016 12:36 AM
> *To:* Avri Doria
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] PTI and the IRP
>
>
>
> Avri,
>
>
>
> I agree with your analysis and share your concern.  The PTI IRP is
> fundamentally not a Bylaws issue (or more accurately -- fundamentally not a
> "violation of the Bylaws" issue).
>
>
>
> Having "borrowed" the IRP in an attempt to fill the requirements of the
> CWG, we can't then pretend that the requirements of the CWG are coterminous
> with the general design of the IRP.  The CWG's requirements will require a
> specific statement of the basis on which a claim may be brought -- and it
> is a different basis than for other IRP claims.  This doesn't have to be
> long, but it does have to be right.
>
>
>
> Conversely, if we are truly wedded to the idea that the IRP is a "bylaws
> court" and nothing more, then it can't be used to satisfy the CWG's
> requirement and we will need to do something else.  Personally, I don't
> endorse this position (though it does raise some concern about the ability
> of the panel to deal with PTI failures, if it is designed to be a bylaws
> court.  That said, I have sufficient faith in the skill of experienced
> arbitrators to be able to resolve a variety of disputes.)
>
>
>
> Since this a requirement for the transition, we need to resolve this
> crisply, explicitly and appropriately.
>
>
>
> Greg
>
>
>
> On Wed, Jan 20, 2016 at 12:25 AM, Avri Doria <avri at acm.org> wrote:
>
> Hi,
>
> I am uncomfortable with closing the discussion of the new principles for
> the IRP.  Since we decided not to create a new entity to serve the
> requirements of the CWG but rather to make it a function of the IRP, we
> need to make sure that the basis for the IRP is fit for purpose before
> starting on its implementation.
>
> The CWG calls for:
>
> > 1.            *Appeal mechanism*. An appeal mechanism, for example in
> > the form of an Independent Review Panel, for issues relating to the
> > IANA functions.  For example, direct customers with non-remediated
> > issues or matters referred by ccNSO or GNSO after escalation by the
> > CSC will have access to an Independent Review Panel. The appeal
> > mechanism will not cover issues relating to ccTLD delegation and
> > re-delegation, which mechanism is to be developed by the ccTLD
> > community post-transition.
> >
>
> I do not see how to define this function in terms of By Laws alone as By
> Laws have little to say about negotiated SLAs and the  customers' or CSC
> complaints.  Perhaps it can be done by changes to some of the By Laws,
> but I do not see us as having scoped out what those changes need to be.
>
> So until such time as we have dealt the the policy issues of filling the
> CWG's requirements, I would like to register a personal caution, and
> thus an objection, to closing the discussion of the basis and standing
> for IRP appeals.  I do not believe this is merely an implementation
> issue.  At least not yet.
>
> avri
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_antivirus&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=9zpJkUMQmkKK1JJZ4UjZmt9rbYe2_te6YMKJgHLAMCs&s=hrS-SjNieBsQS3g-4IaOCuqnhva_tsA1TDs8a0zMOOQ&e=>
> ------------------------------
>
> *BrettSchaefer*
>
> * Jay Kingham Senior Research Fellow in International Regulatory Affairs
> Margaret Thatcher Center for Freedom Davis Institute for National Security
> and Foreign Policy*
> The Heritage Foundation
> 214 Massachusetts Avenue, NE
> Washington, DC 20002
> 202-608-6097
> heritage.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=9zpJkUMQmkKK1JJZ4UjZmt9rbYe2_te6YMKJgHLAMCs&s=VeYpm4OC3DluvWT6BqP7fLSRT7eOV0sSm9Vw5RR91S4&e=>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=9zpJkUMQmkKK1JJZ4UjZmt9rbYe2_te6YMKJgHLAMCs&s=L5e8VgjjxxQ3JnJo5baWM3AIcoofHz8l8EplNcQIZag&e=>
>
>
>
>
>
>
> ****************************************************************************************************
> This e-mail is sent by a law firm and may contain information that is
> privileged or confidential.
> If you are not the intended recipient, please delete the e-mail and any
> attachments and notify us
> immediately.
>
>
> ****************************************************************************************************
>
> _______________________________________________
> Cwg-client mailing list
> Cwg-client at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-client
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-client/attachments/20160120/6bc8d194/attachment-0001.html>