[Gnso-bylaws-dt] Meeting with ccNSO GRC tomorrow - thoughts on questions

Mon Jul 15 12:00:02 UTC 2019

Thanks David,

I think the basic question here is which role and responsibility the 
SICT shall be allowed to take. For me it is a small WG taking some 
preparatory workload from the councils in order to put them in a 
position to tke decisions.

Looking forward to hearing you in some minutes

Wolf-Ulrich

Am 14.07.2019 um 22:23 schrieb McAuley, David via Gnso-bylaws-dt:
>
> Dear Heather and members of the GNSO drafting team,
>
> In preparing for the call tomorrow with the ccNSO Guidelines Review 
> Committee, I’d like to note my suggestions on the questions we will be 
> looking at tomorrow, given my unique perspective as a member of both 
> teams.
>
> Here are the questions, followed by my recommendations in red-italics:
>
>  1. We envision the creation of a GNSO-ccNSO Special IFR Initiation
>     Coordination Team (SICT) – see paragraph 5.2. We say that as soon
>     as the CSC informs the ccNSO and GNSO Councils about a performance
>     issue as defined in the CSC Remedial Action Procedure, the two
>     Councils shall as soon as possible each appoint three (3) members
>     including the Chairs to the SICT. Well, these CSC procedures
>     involve going first to the PTI Board, then the ICANN CEO, and then
>     to the ICANN Board. The GRC wonders when specifically should the
>     SICT be established and they suggest that it not be until the
>     ICANN Board is engaged in the matter. (Note – The CSC will inform
>     the Councils of every escalation step in the RAP.)
>
> a.Question: Do we agree? What do we think?
>
> */It seems like a sensible suggestion to me. The Board will take at 
> least a little time to react and with this joint guideline the SICT 
> ought to be able to get prepared. It might make sense, however, for 
> both Councils (when they adopt this guideline) to create an annual 
> reminder on their agendas of what a SICT is and whom they might 
> consider as likely candidates should the need arise. /*
>
>  2. In reading through paragraph 5.3, the GRC was not quite sure
>     whether the respective Councils would have to make one joint
>     statement or two – and how the interplay takes place between
>     posting input on the various websites and jointly releasing a
>     statement through the SICT.
>
>   a. Question: Can we clarify how this process works?
>
> b. Related question: Can we two groups jointly map out the timeline of 
> the SICT to test its viability? (For instance, we allow up to 30 days 
> for input from SOs and ACs (see last sentence of paragraph 4.4) and 
> then perhaps allow for the time needed for public comment – will these 
> time periods work?)
>
> *//*
>
> */Paragraph 5.3 currently says this in part: ‘/**/The GNSO and ccNSO 
> shall jointly release a statement through the SICT that they are 
> initiating a Joint Consultation …’/*
>
> *//*
>
> */That sounds to me as if there is just one statement and it comes 
> from SICT. Maybe SICT can sign off on such a statement and then below 
> its signature could be approval signature-blocks for ccNSO and GNSO. /*
>
> *//*
>
> */On timing, I think a ‘dry-run’-through makes good sense. But I also 
> suggest that we consider an overarching timing-paragraph along these 
> lines:/*
>
> */__/*
>
> */_Flexible construction of time periods within this document_:/*
>
> */__/*
>
> */_Each time period specified in this document within which any 
> decision or other action must be made shall be understood as being a 
> ‘not-greater-than’ time period, it being understood that in all 
> instances, as well as cumulatively, the individual or group (e.g. 
> Council Chair or SICT) having to decide or act shall decide or act so 
> as to remain within the times specified under the ICANN 
> Bylaws(including the Annexes to such Bylaws). _/*
>
>  3. For the work and deliberations involved in paragraphs 5.4 through
>     5.6 (this is a considerable amount of work) the document places
>     most of the onus on the SICT. THE GRC wonders if this is too much
>     to load onto the SICT and whether some of this should be shifted
>     to the respective Councils – and what that balance would look like
>     in a bit more detail. Moreover, given the ramifications of the
>     decisions involved which decision should be on the plate of the
>     full Councils and which on the plate of the coordination team?
>
>  1. Question: What do we think?
>
> */This also seems sensible – and maybe a good division would be to 
> assign duties in 5.4 and 5.6 to SICT, and those in 5.5 to Councils. /*
>
> *//*
>
>  4. With respect to considerations of a Special IFR itself, the GRC
>     noted that other avenues exist through which to address PTI issues
>     – for instance (1) possible removal of director(s) and (2) the
>     ability to bring an IRP relating to PTI service complaints and/or
>     ICANN’s failure to enforce its rights under the IANA Naming
>     Functions Contract – and mediation is also available.
>
>  1. Question: Should this document note the fact that Councils will
>     possibly be looking at alternative courses of action and thus we
>     should be careful to check on that possibility to factor it into
>     our calculations?
>
> */This seems wise, at least for the SICT (assume that Councils will 
> remain abreast of developments in other avenues) – maybe a sentence at 
> the end of section 5.2 along these lines:/*
>
> */__/*
>
> */_In addition, the SICT shall take steps to remain informed of 
> developments at resolving the PTI Performance Issue(s) by other means 
> and shall consider such developments as they may reasonably influence 
> the work of the SICT without jeopardizing the SICT’s ability to remain 
> within the timeline(s) specified by the Bylaws (including Annexes to 
> the Bylaws). _/*
>
>  5. Finally, the document should perhaps make reference to ongoing
>     steps by CSC to resolve the issue. What happens if the PTI/IANA
>     issue is resolved along the way – should we address closing down
>     the SIFR and SICT. (Note – once the CSC informs the Councils at
>     the end of the RAP the role of the CSC is very limited – see the
>     RAP process [icann.org].)
>
> */This seems sensible, but I would like to hear a bit more from Bart 
> about what this might look like. /*
>
> Best regards,
>
> David
>
> David McAuley
>
> Sr International Policy & Business Development Manager
>
> Verisign Inc.
>
> 703-948-4154
>
>
> _______________________________________________
> Gnso-bylaws-dt mailing list
> Gnso-bylaws-dt at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-bylaws-dt
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-bylaws-dt/attachments/20190715/ebc864bc/attachment-0001.html>