[DTC CSC] FW: [DTM Escalation] For your review - proposed public comment responses

Thu Jun 4 10:07:28 UTC 2015

All,

FWIW, I believe that a tightly scoped (“minimalist”) role for the PTI board
is not inconsistent with it being a step in the escalation process.

I’ll add below the latest drafting from Sidley (paras 110 & 111) which seems
to me to support that (my colour / emphasis).

Thanks,

Jonathan

As a separate legal entity, PTI would have a board of directors or managers.
The PTI Board

will would be an ICANN-designated board and have the minimum statutorily
required

responsibilities and powers. The construct of the PTI Board would be a range
of 3-5 people

with,to be appointed by ICANN as the sole member of PTI. The PTI Board could
be

comprised of three directors who are employed by ICANN or PTI (for example,
the ICANN

Executive responsible for PTI, the ICANN CTO, and the IANA Managing
Director), and two

additional independent directors. 6 (who may or may not be members of the
ICANN Board).6

The two additional directors could be nominated using an appropriately
rigorous nomination

mechanism (e.g., by the Nominating Committee of the ICANN Board).The
CWG-Stewardship

expects that this would avoid the need to replicate the complexity of the
multistakeholder

ICANN Board at the PTI level, and maintain primary accountability at the
ICANN level. Any

issues that arise concerning the PTI and the PTI Board would be addressed
through the

overarching ICANN accountability mechanisms.7

The function of the PTI Board is to provide oversight of the operations of
PTI to

ensure that PTI meets, at a minimum, applicable statutory requirements under
California

public benefit corporation laws and, importantly, fulfills its
responsibilities under the IANA

functions contract with ICANN.

From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk] 
Sent: 04 June 2015 08:13
To: Duchesneau, Stephanie; Staffan Jonson; dt3 at icann.org
Subject: Re: [DTC CSC] FW: [DTM Escalation] For your review - proposed
public comment responses

Stephanie,

I don’t think so, but I’m not sure collectively we have made the point about
limiting PTI Board responsibilities.

But I fully agree that the PTI Board has a minimalistic role.  For the CSC,
the PTI Board is essentially an opportunity we have to push for improvements
as we look for remedial action.  If there is no action, then the CSC could
discuss with the ICANN Board.  We agreed in thinking about the CSC that the
key role was to promote remedial (cooperative) action and the PTI Board is a
key part of that.  That’s clearly a PTI Board role as keeping IANA
operations running smoothly.

Martin

From: Duchesneau, Stephanie [mailto:Stephanie.Duchesneau at neustar.us] 
Sent: 03 June 2015 03:19
To: Martin Boyle; Staffan Jonson; dt3 at icann.org
Subject: Re: [DTC CSC] FW: [DTM Escalation] For your review - proposed
public comment responses

I am of the camp that the PTI board role should be kept minimalist which
this seems to get in the way of. Has the CWG moved against keeping the board
responsibilities to what would be required of a PBC and necessary to keep
IANA operations running smoothly?

Why is this information not being rolled out to the customers to determine
whether IFR is warranted by and through ccNSO and GNSO (or RySG)?

Stephanie

Stephanie Duchesneau 

Neustar, Inc. / Public Policy Manager
1775 Pennsylvania Avenue NW, 4th Floor, Washington, DC 20006
Office: +1.202.533.2623 Mobile: +1.703.731.2040  Fax: +1.202.533.2623 /
<http://www.neustar.biz/> www.neustar.biz     

From: Martin Boyle <Martin.Boyle at nominet.org.uk>
Date: Tuesday, June 2, 2015 at 3:02 PM
To: Staffan Jonson <staffan.jonson at iis.se>, "dt3 at icann.org" <dt3 at icann.org>
Subject: Re: [DTC CSC] FW: [DTM Escalation] For your review - proposed
public comment responses

DT-C was always clear – that we enter remedial action with the PTI Board as
(just about) the last step.  I think CSC (as under ICANN) escalates to the
ICANN Board.  We are then telling the ICANN Board that it needs to sort its
subsidiary out.

The DT-M group seems to me to be confusing who has the role with whom.  I’m
finding this proposal very confusing in lines of accountability and
responsibility.

Martin

From: dt3-bounces at icann.org [mailto:dt3-bounces at icann.org] On Behalf Of
Staffan Jonson
Sent: 02 June 2015 19:53
To: dt3 at icann.org
Subject: [DTC CSC] FW: [DTM Escalation] For your review - proposed public
comment responses

Below for information

Staffan

staffan.jonson at iis.se

 +46 73 317 39 67

Från: Marika Konings <marika.konings at icann.org>
Datum: tisdag 2 juni 2015 19:39
Till: "DT-M (dt6 at icann.org)" <dt6 at icann.org>
Ämne: [DTM Escalation] For your review - proposed public comment responses

Dear All, 

Please find below the notes from today’s DT-M meeting. Based on those
discussions, the proposed responses to the DT M related comments are as
follows:

CSC should escalate to the PTI Board who may ask for a review (from the IFR)
or any other action (AFRALO) – DT M

DT M agrees that the CSC should have the ability to escalate to the PTI
Board as a step prior to escalation to the ccNSO/GNSO and has updated the
IANA problem resolution process accordingly. Furthermore, the DT M agrees
that the PTI Board should be able to submit a request to the ICANN Board to
initiate a SIFR. The ICANN Board is expected to consider such a request
making use of the customary community consultation mechanisms. As such, DT M
suggests that DT N/SR updates the separation process accordingly and notes
that a reference to this possibility should also be included in the IANA
problem resolution process. 

Escalation by CSC to GNSO and ccNSO is adding a layer of escalation that may
not be necessary. CSC could call for SIFR instead. (Centre for Democracy &
Technology) – DT M

The CSC charter was largely done prior to the discussions on the PTI Board,
as such escalation to the GNSO and ccNSO was the chosen escalation path at
the time. Escalation to IFR was considered beyond the scope of the CSC,
instead as any issues raised would relate directly to the technical
performance of IANA, ccNSO and GNSO were considered to have direct access to
broader community input on this issue and would be in a position to make an
assessment on appropriate next steps. The GNSO and ccNSO step is an approval
step with multi-stakeholder involvement, not an escalation mechanism as
such. Having only the CSC initiate an SIFR may not be appropriate
considering its limited remit and size.

Question from intensive working sessions: Should CWG consider whether GNSO
should be changed to RySG – ccNSO and RySG would consider whether it should
be escalated to a multi-stakeholder process to determine next steps?

DT M proposes to keep escalation to ccNSO and GNSO instead of RySG noting
that the equivalence between RySg and the ccNSO is a false equivalence. Both
name supporting organization organizations are multistakeholder
organizations. In the GNSO there is a global organization of the stakeholder
into separate SGs and Constituencies. The ccNSO is a local stakeholder
organization so that according to RFC 1591, each of the ccTLD is a self
contained multistakeholder entity.

Inconsistencies between CSC and its responsibilities and the IFR (NCSG) – DT
M

CWG Response: The CSC charter was largely done prior to the discussions on
the PTI Board, as such escalation to the GNSO and ccNSO was the chosen
escalation path at the time. As a result, there may be inconsistencies
between CSC and IFR escalation mechanisms. The aim is to address these in
the next iteration of the proposal. 

All deliberations and output should be transparent. CSC should not escalate
to ccNSO or GNSO as these are policy bodies. (ALAC) – DT C

DT M understands the concern but practical considerations of using existing
structures have enough advantages to support going this direction.
Furthermore, DT M notes that GNSO has explored the relationship between
implementation of adopted GNSO policies, and as such can raise alarms and
request a SIFR. Also, DT M observes that the GNSO is about more than only
policy and has views of all things ICANN, such as strategy and budget.

Please provide your input by COB today (Tuesday 2 June) so that the
responses can be shared with the CWG tomorrow.

Thanks,

Marika

Notes DT M meeting – 2 June 2015

Footnote 36 -  consider timing of this work. DT to review section 4
(implementation considerations) to determine whether any updates
could/should be made there to reflect work that is needed in relation to
mediation options. 

DT M / DT C to co-ordinate where input regarding punch list items #21 - 23 -
where will the agreed approach be incorporated? ccNSO & GNSO to undertake
further work on this issue - might be another implementation item to be
included in section 4.

DT M to consider whether esclation in problem management in step 4 should be
to ccNSO/GNSO or ccNSO/RySG.

Escalation to PTI Board can be a useful step as it could result in
correction of issue, even if changes are small that PTI Board is able to
correct the issue if it has not been addressed before by PTI staff. If issue
is not addressed by PTI Board, issue would be escalated to ccNSO/GNSO. 

Should PTI Board be able to ask for review by SIFR? PTI Board could request
SIFR and submit this request to the ICANN Board. ICANN Board with community
input could then make a decision on whether or not an SIFR is initiated. PTI
Board should not be making such a request to the CSC. DT N/SR/X to consider
this update as part of the separation process annex. DT M also consider
making reference to this in the section (for example as a footnote) on
escalation mechanisms, following CWG agreement on including this. 

DTM proposes to keep escalation to ccNSO and GNSO instead of RySG noting
that the equivalence between RySg and the ccNSO is a false equivalence. Both
name supporting organization organization are multistakeholder
organizations. In the GNSO there is a global organization of the stakeholder
into separate SGs and Constituencies.In the ccNSO the is a local stakeholder
organization so that according to RFC 1591, each of the ccTLD is a self
contained multistakeholder entity.

In response to ALAC comment: DT M understands concern but practical
considerations of using existing structures have enough advantages to
support going this direction. DT M also notes that GNSO has explored the
relationship between implementation the policis made, and can raise alarms
and request a SIFR; 2. GNSO is about more than policy and has views of all
things ICANN, such as strategy and budget.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt3/attachments/20150604/9b568b6e/attachment-0001.html>