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@icann.org<mailto:marika.konings@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-e...>.
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@icann.org> Sent at:2018 Jun 6 (Wed) 00:58 To:GNSO Council List <council@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@icann.org Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.
Thanks, Pam - We'll follow up ASAP. Best wishes, Heather On Fri, Jun 8, 2018 at 8:46 AM, Pam Little <pam.little@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@icann.org> Sent at:2018 Jun 6 (Wed) 00:58 To:GNSO Council List <council@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@icann.org <marika.konings@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-e...>. *
_______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
Thank you very much for following up, Heather. I hope that this document will be made available shortly. It is difficult to scope our work without it. It might be useful to have a new [Accountability Indicator](https://www.icann.org/accountability-indicators) to assess when commitments are made to the community - and deadlines committed to are not adhered to. This would be a great deal more meaningful than many of the indicators we have at present. —Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 8 June 2018 4:10 AM, Heather Forrest <haforrestesq@gmail.com> wrote:
Thanks, Pam - We'll follow up ASAP.
Best wishes,
Heather
On Fri, Jun 8, 2018 at 8:46 AM, Pam Little <pam.little@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@icann.org> Sent at:2018 Jun 6 (Wed) 00:58 To:GNSO Council List <council@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@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-e...).
_______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
participants (4)
-
Ayden Férdeline -
Heather Forrest -
Marika Konings -
Pam Little