[council] Notes from GNSO Council - ICANN Board meeting to discuss next steps following the Board's adoption of the temporary specification for gTLD Registration Data

Fri Jun 8 02:10:58 UTC 2018

Thanks, Pam - We'll follow up ASAP.

Best wishes,

Heather

On Fri, Jun 8, 2018 at 8:46 AM, Pam Little <pam.little at alibaba-inc.com>
wrote:

> Is there any update on (9) below?
>
> *(9) Does ICANN have/will ICANN develop a list of policies and contractual
> clauses that are impacted by the temporary specification (beyond what is
> currently identified in the Annex)? This would help with scoping the work.*
>
>
>
>    - ICANN Org is in the process of preparing a list which should be
>    ready for sharing shortly. Once published, all input is welcome. ICANN
>    Org to follow up with the Council on the expected timing within 24 hours. If
>    possible, would be helpful to have this document prior to the upcoming
>    Council meeting (12 June).
>
>
> Kind regards,
>
> Pam
>
> ------------------------------------------------------------------
> Sender:Marika Konings <marika.konings at icann.org>
> Sent at:2018 Jun 6 (Wed) 00:58
> To:GNSO Council List <council at gnso.icann.org>
> Subject:[council] Notes from GNSO Council - ICANN Board meeting to discuss
> next steps following the Board's adoption of the temporary specification
> for gTLD Registration Data
>
> Dear All,
>
>
>
> Please find below the notes from today’s GNSO Council – ICANN Board
> meeting to discuss next steps following the Board’s adoption of the
> temporary specification for gTLD Registration Data. Note that the recording
> and transcript of the meeting will be circulated shortly. These
> high-level notes are designed to help the Council  navigate through the
> content of the call and are not meant as a substitute for the transcript
> and/or recording.
>
>
>
> Best regards,
>
>
>
> Marika
>
>
>
> ==================
>
>
>
> *Board-GNSO Council Call*
>
> *Next steps following Board adoption of Temporary Specification*
>
> 5 June 2018
>
>
>
> Questions have been divided into three categories:
>
>    - Scope
>    - Timing
>    - Participation
>
>
>
> This is unchartered territory so a degree of flexibility of all involved
> will be required. Nevertheless, the Council is the manager of the PDP and
> as such, the Board expects the Council to take on this role and has no
> intention to interfere.
>
>
>
> Aim to answer as many questions as possible today and for those for which
> it is not possible to provide an answer, identify who and when an answer
> can be provided.
>
>
>
> Number of questions overlap, including in the questions between the
> Council and the Board, so not every question may need an answer as it may
> already get answered in response to another question.
>
>
>
> *(4) What is the intent of the EPDP? Is it simply to confirm the Temporary
> Specification, or something more? What room is there in scoping to
> anticipate that the EPDP may conclude that the Temporary Specification
> cannot be confirmed “as is”, and make changes in order to achieve consensus
> policy?  *
>
>
>
>    - Key is flexibility, need to work collegially and flexible. Not set
>    things in stone - deal with issues and problems as they arise. In the
>    Board's view there is room for various outcomes: confirming temporary
>    specification; developing a different approach from what is established in
>    the temporary specification; addressing additional issues that are not
>    specifically identified in the temporary specification but for example, the
>    annex. Is for the GNSO Council to manage, but Board stands ready to assist
>    as needed. Any outcome will obviously need to comply with the law.
>
>
>
>    - 12 month deadline needs to inform the scoping. Need to understand
>    whether some of the additional items called out in the annex could be dealt
>    with differently.
>
>
>
> *(5) The Temporary Specification reasoning for including WHOIS as a
> security and stability issue is based on the new ICANN Bylaws; at time of
> contract signing, that wasn’t the case. Doesn’t that open a possible avenue
> to challenge it altogether? Wouldn’t phasing the EPDP allowing a quick
> Consensus Policy made of uncontroversial parts of the Temp Spec increase
> the assurances that this wouldn’t hamper ICANN Org’s compliance ability?*
>
>
>
>    - Response to this question needs to be further discussed.
>
>
>
> *(6) What happens should the Board decide to either modify the Temporary
> Specification or completely replace the temporary specification by a new
> one at a later point in time? Does this change the scope of the ongoing
> EPDP (note: Council does not intend to run multiple EPDPs simultaneously),
> and if so, how is the EPDP expected to deal with such changes while it may
> be half way through its process?*
>
>
>
>    - Need to be flexible. If there is an amendment to the temporary spec,
>    the circumstances need to be considered. An amendment in month 1 may be
>    dealt with differently compared to one in month 11. Similarly the type of
>    amendment - minor or substantial. It may also be possible that a new
>    temporary spec is triggered on a certain issue that in theory would trigger
>    a new PDP, although it might be possible to fold this into the existing
>    PDP. Flexibility is key, need timely communication to ensure that the
>    appropriate approach can be considered factoring in all circumstances.
>    Board does not want to use the temporary specification approach unless
>    absolutely necessary, for example when guidance is received from DPAs that
>    certain elements would need to be changed.
>
>
>
>    - Need some boundaries around how changes are dealt with as that may
>    provide some needed clarity, especially to (E)PDP Team in case changes
>    occur. The more that can be reached agreement on in the early stages, the
>    better. Ensure common understanding of possible scenarios.
>
>
>
>    - Consider parking lot approach to park issues that need to be dealt
>    with, but which may not be urgent.
>
>
>
> *(9) Does ICANN have/will ICANN develop a list of policies and contractual
> clauses that are impacted by the temporary specification (beyond what is
> currently identified in the Annex)? This would help with scoping the work.*
>
>
>
>    - ICANN Org is in the process of preparing a list which should be
>    ready for sharing shortly. Once published, all input is welcome. ICANN Org
>    to follow up with the Council on the expected timing within 24 hours. If
>    possible, would be helpful to have this document prior to the upcoming
>    Council meeting (12 June).
>
>
>
> *(8) The Temporary Specification covers a number of additional policies
> that go beyond the requirements of the RA and RAA as they relate to
> Registration Data Directory Services. How does the Board believe the GNSO
> Council should handle these areas of overlap?*
>
>
>
>    - How does the GNSO currently deal with this? In unchartered territory
>    here as we are working of a temporary specification, that is normally not
>    the scenario in a normal PDP. For example, the temp spec refers to SLAs for
>    RDS services - that would normally be an implementation matter, not a
>    policy matter. Need to consider this question further.
>
>
>
> *(10) What happens if the GNSO is not able to reach consensus at the end
> of the 1 year period? (see also Timing)*
>
>
>
>    - Board to explore other ways forward. Absent another way forward
>    there are things that automatically occur at the end of the 12 month period
>    - temp spec would no longer be in force. Review throughout the 12 month
>    period how things are going, would allow Board to explore alternative ways
>    forward which could potentially buy more time. The longer it takes, the
>    greater the likelihood is that decisions are taken outside of ICANN. If
>    community wants to be in control, needs to work in a timely manner.
>
>
>
> *(11) How does the Board expect the EPDP to follow and/or to incorporate
> ICANN´s ongoing legal strategy and the decisions of EU country courts? *
>
>
>
> *(12) As evidenced by the recent legal action involving EPAG, there are
> parties who believe aspects of the Temporary Specification as written are
> not compliant with the GDPR. How does the Board think the GNSO Council
> should approach this matter when structuring and scoping the PDP?*
>
>
>
>    - Ongoing court cases may have an impact on issues, but the (E)PDP
>    Team is not expected to deliberate on these issues unless these are
>    reflected in the temporary specification.
>
>
>
> *(4) Does the initial 90-day (and maximum one-year) period - and thus the
> maximum timeline for the GNSO’s policy work - commence on 17 May (date of
> Board resolution) or 25 May (effective date of the temporary
> specification)? We note that the operative language from the RAA/RA
> specifies that “In establishing any Temporary Policy, the Board shall state
> the period of time for which the Temporary Policy is adopted and shall
> immediately implement the Consensus Policy development process set forth in
> ICANN's Bylaws”, and the Board resolution is clear that the specification
> is effective beginning on 25 May. This could be interpreted to mean that
> the one-year clock starts from the effective date of the specification
> rather than Board action via resolution, which is a difference of 8 days.*
>
>
>
>    - 25 May 2018 is the starting point, so 1 year period would end on 24
>    May 2019. Up to the Council to decide when to start, but regardless,
>    process has to complete by 24 May 2019.
>
>
>
> *(5) What happens should the Board decide to either modify the temporary
> specification or completely replace the temporary specification by a new
> one at a later point in time? Does the amended temporary specification
> become a new temporary specification, effectively re-starting the clock on
> the Temp Spec and the ongoing EPDP? If changes to the Temporary
> Specification as it is today are certain to occur, and the amended
> temporary specification becomes a new temporary specification, why not
> delay starting the ePDP (assuming clock re-starts)? Note Council’s
> intention is not running multiple EPDP, but rather revising scope of the
> one ongoing EPDP*.
>
>
>
>    - Will depend on facts and circumstances. Board wants to continue to
>    consult, could include appointing a liaison to the (E)PDP Team, small Board
>    caucus to liaise with the Council, etc. Board wants to help without seeking
>    to impose views.
>
>
>
>    - Need the ability for instant consultation noting the possible moving
>    parts and the need to be flexible. What does "consult" mean? Council
>    weighing in on decision-making? More looking from the perspective of the
>    Council being able to consult with the Board as needed. Board would talk to
>    different parties and factor in input - if a particular way or structure is
>    preferred, this can be discussed.
>
>
>
> *(1) Participation of the GAC: How will the EPDP take into account GAC
> advice? Should the Board facilitate a session between the GNSO and the GAC
> on this issue, and when?*
>
>
>
>    - Would be good to discuss with GAC what is possible and feasible.
>    Need to open up channels of discussion, recognising that the GNSO is in
>    charge and leading.
>
>
>
> *(6) How is the re-confirmation process expected to occur as the temporary
> policy is only valid for 90 day intervals?*
>
>
>    - Board will hold meetings at 90 day intervals and review prior to
>    each meeting whether there is any new guidance that may require changes,
>    followed by renewal of temporary specification for another 90 days. Changes
>    may need to happen outside of that cycle.
>
>
>
> *(7) Has the Board considered what actions it may take in the event that,
> at the end of the one-year period, the Temporary Specification is not
> confirmed as a Consensus Policy and no other Consensus Policy has been
> developed to replace it?*
>
>
>
>    - See previous response to similar question.
>
>
>
> ========
>
>
>
> If more discussion is helpful, Board is willing and available.
>
>
>
> Need to determine which questions need to be followed up on and timeline
> for those. Develop task list as a result. Could include request for further
> calls. Council holding extraordinary meeting on 12 June to further discuss
> next steps.
>
>
>
> *Marika Konings*
>
> *Vice President, Policy Development Support – GNSO, Internet Corporation
> for Assigned Names and Numbers (ICANN) *
>
> *Email: marika.konings at icann.org <marika.konings at icann.org>  *
>
>
>
> *Follow the GNSO via Twitter @ICANN_GNSO*
>
> *Find out more about the GNSO by taking our interactive courses
> <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages
> <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>. *
>
>
>
>
>
> _______________________________________________
> council mailing list
> council at gnso.icann.org
> https://mm.icann.org/mailman/listinfo/council
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20180608/01c23506/attachment-0001.html>