[DTM Escalation] DTM Tuesday meeting and PTI board role in SIFR
Gomes, Chuck
cgomes at verisign.com
Thu Jun 4 03:35:59 UTC 2015
Thanks Avri.
Chuck
-----Original Message-----
From: dt6-bounces at icann.org [mailto:dt6-bounces at icann.org] On Behalf Of Avri Doria
Sent: Wednesday, June 03, 2015 11:32 PM
To: dt6 at icann.org
Subject: Re: [DTM Escalation] DTM Tuesday meeting and PTI board role in SIFR
hi,
I think it Chuck option 1 is right thing to do. I do not accept 2, 3 or 4. I think we should avoid terms like minimalistic in the recommendations.
But we removed the Board from the path in initiating a SIFR, and adding that new requirement for the PTI's sake is bound to make some people anxious. Though I would be happy to include board approval to intiate a SIFR.
So if we are going to go back on yesterday's recommendaton, we should remove it and remain silent on the issue. After all it was just an idea in response to a comment from one commenter. In the response list we can say we thought about it and decided: meh, nah.
avri
On 03-Jun-15 09:15, Gomes, Chuck wrote:
>
> 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.
>
>
>
> _______________________________________________
> dt6 mailing list
> dt6 at icann.org
> https://mm.icann.org/mailman/listinfo/dt6
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
dt6 mailing list
dt6 at icann.org
https://mm.icann.org/mailman/listinfo/dt6
More information about the dt6
mailing list