[Info] MP3, Adobe Connect recording and chat transcript/ GNSO Council with the ICANN Board meeting to discuss next steps following the adoption of ICANN Board of the temporary specification on Tuesday 5 June 2018 at 13:00 UTC.

Tue Jun 5 16:48:08 EEST 2018

Hi all,

please find here the recordings and the high level notes of the call
between GNSO council and Board on next steps for temporary specification

Best Regards,

Rafik

==================

*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.

---------- Forwarded message ---------

Dear GNSO Council,

Please find below the MP3, Adobe Connect recording and chat of the GNSO
Council with the ICANN Board meeting to discuss next steps following the
adoption of ICANN Board of the temporary specification held on Tuesday 5
June 2018 at 13:00 UTC.

MP3: https://audio.icann.org/gnso/gnso-council-icann-board-05jun18-en.mp3

Adobe Connect Recording URL:  https://participate.icann.org/p6ai9gt1qeg/

Adobe Connect chat at:
https://gnso.icann.org/en/meetings/transcript-chat-council-icann-board-05jun18-en.pdf

All on page: https://gnso.icann.org/en/group-activities/calendar

Thank you.

Happy listening and reading!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20180605/631721f3/attachment.htm>