[DTM Escalation] DTM Tuesday meeting and PTI board role in SIFR

[Gomes, Chuck]

Thanks Staffan.  Your additional thoughts on this are very welcome.  While I do not feel very strongly one way or the other on this and probably can go either way myself, I have inserted some of my own thoughts below.

All:  Note that I provide four options below that I would like everyone to respond to in the next few hours if possible.

Chuck

From: dt6-bounces at icann.org [mailto:dt6-bounces at icann.org] On Behalf Of Staffan Jonson
Sent: Wednesday, June 03, 2015 3:05 AM
To: Marika Konings; DT-M (dt6 at icann.org); dt3 at icann.org
Subject: [DTM Escalation] DTM Tuesday meeting and PTI board role in SIFR

Lists
Re. Yesterdays meeting in DTM

It was yesterday suggested to add a point 3 (appendix J, p 74) allowing also for the PTI board to initiate a SIFR.
I was presented this proposal for change of text 'a vista', in sitting meeting. Since I saw no immediate issues with it I agreed hesitatingly (hesitation was also confirmed by Chuck) .

In Marikas summary this was formulated as:
"... the DT M agrees that the PTI Board should be able to submit a request to the ICANN Board to initiate a SIFR."

Having considered overnight, and listening into whole DT C, I suggest a step back, *not* going further with changes already made before yesterdays meeting. My proposal is therefore to strike out point 3 from yesterdays alteration (and any consequent changes in other parts of the text).

Reason for suggesting this:
Even though I support many parallel options of raising concern and even escalation in community, what I didn't see immediately was the secondary effect  that this proposal risk to fundamentally change the balance between ICANN board and PTI board. It is agreed in CWG that the PTI board should be minimalistic and have limited responsibility. The ability for PTI board to escalate at SIFR will skew this relation, and make accountability and responsibility hard to follow.
[Chuck Gomes] Note that we did not recommend that the PTI board could escalate to an SIFR.  What we recommended was that "the PTI Board should be able to submit a request to the ICANN Board to initiate a SIFR".  The key word in my view is "request".  The ICANN Board would have the power to initiate a SIFR, not the PTI Board. The PTI Board could only request that the ICANN Board consider initiating a SIFR.  To make this clearer, we could reword it something along these lines: "DT M does not believe that the PTI Board in its minimalistic and limited responsibility should be able to initiate a SIFR but suggests that the PTI Board could send a request to the ICANN Board that it consider initiating a SIFR and provide the rationale for their request."

That said, it seems to me that there is nothing that would prevent the PTI board from issuing such a request whether we recommend they can do that or not.  If I am correct about that, we could change our recommendation to something like this: "DT M does not believe that the PTI Board in its minimalistic and limited responsibility should be able to initiate a SIFR but we note that there is nothing that would prevent the PTI board from suggesting that the ICANN Board consider initiating a SIFR and providing its rationale for that suggestion."

Since we cat CWG meeting also opened up for growing the PTI board (at the boards own discretion) there is was to achieve some Liason role and communications by other means.

I hope we can resolve this during Wednesday, before CWG thursday.
[Chuck Gomes] Taking from the responses I added above, I see at least four options for DT-M:

1)      Leave the recommendation as is: "DT M agrees that the PTI Board should be able to submit a request to the ICANN Board to initiate a SIFR."  (After reflecting on this further, I personally oppose this option because I don't think it addresses the point you made about the 'minimalistic and limited responsibility of the PTI Board and because it states that we agree with the commenters suggestion when we are really not fully agreeing.)

2)      Change the recommendation to something like this: "DT M does not believe that the PTI Board in its minimalistic and limited responsibility should be able to initiate a SIFR but suggests that the PTI Board could send a request to the ICANN Board that it consider initiating a SIFR and provide the rationale for their request."

3)      Change the recommendation to something like this: "DT M does not believe that the PTI Board in its minimalistic and limited responsibility should be able to initiate a SIFR but suggests that the PTI Board could send a request to the ICANN Board that it consider initiating a SIFR and provide the rationale for their request."

4)      Delete the recommendation and say: "DT M does not believe that the PTI Board should be able to initiate a SIFR because of its in its minimalistic and limited responsibility."

[Chuck Gomes] I personally could support 2), 3) or 4) and request that the rest of you voice your preferred option(s) or add a new option if you like.  But please do that right away so we can determine whether we can reach some consensus.  If everyone who responds could not support 2) or 3), I suggest we go with 4).

Staffan

staffan.jonson at iis.se<mailto:staffan.jonson at iis.se>
+46 73 317 39 67





Från: dt6-bounces at icann.org<mailto:dt6-bounces at icann.org> [mailto:dt6-bounces at icann.org] För Marika Konings
Skickat: den 2 juni 2015 19:40
Till: DT-M (dt6 at icann.org<mailto: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/dt6/attachments/20150603/d9582984/attachment-0001.html>