[Gnso-epdp-team] Notes, action items and outcomes of today's EPDP Team meeting
Kavouss Arasteh
kavouss.arasteh at gmail.com
Fri Jan 25 19:37:11 UTC 2019
Dear Kurt,
Thanks for reply.
Yes you are right but this could be amended by adding a qualifier at the
Beginning similar to the language used in current draft for Recommendation
12..
*The EPDP Team recommends that , subject to further analysis to be done at
later stage , the ICANN shall ensure that the requirements related to the
accuracy of registration data as stipulated in paragraph 5.1d of Article 5
of GDPR are maintained ,on an intérim basis *
Regards
Kavouss
On Fri, Jan 25, 2019 at 5:23 PM Kurt Pritz <kurt at kjpritz.com> wrote:
> Hi Kavouss:
>
> Thank you for this recommendation and I apologize for getting back to you
> some days later on it.
>
> My recollection was this was discussed at the Team level. (If that
> recollection is faulty, we discussed a similar issue and can apply the same
> rationale that I describe below.)
>
> I believe your proposal is an accurate gauge of the team sentiment.
> However, the recommended change essentially states, we will comply to the
> GDPR, which is what we are trying to do in every case. I remember, either
> in this case or another, similar language was debated and it was determined
> that language merely echoing the GDPR would not be appropriate.
>
> If you disagree with this - let’s discuss it offline to see if there is
> another way to address your concern.
>
> Thanks and best regards,
>
> kurt
>
>
> On Jan 22, 2019, at 6:36 PM, Kavouss Arasteh <kavouss.arasteh at gmail.com>
> wrote:
>
> Dear All,
> We have discussed at length the text of this Recommandation which is
> currently drafted as follows
> *Recommendation #3 WHOIS Accuracy – “The EPDP Team recommends that
> requirements related to the accuracy of registration data under the current
> ICANN contracts and consensus policies shall not be affected by this
> policy” *
> The lagunage used in this Recommandation referred to the current ICANN
> Contract the "*requirements related to the accuracy of registration data
> "*in a defensive (negative )connotation without any clear référence to
> GPDR requirements in Article 5 ( 5d1)
> In order to mitigate the case I suggest the following wording
> *Recommendation #3 WHOIS Accuracy – “The EPDP Team recommends that
> ICANN shall ensure that the requirements related to the accuracy of
> registration data as stipulated in paragraph 5.1d of Article 5 of GDPR are
> maintained *
> *This modification is precise, conise and implicitly refers to the **current
> ICANN contracts .The concept suggested by Farzaneh during the call and I
> slightly amend that to take into account of views expressed after her
> suggestion ,in particulier, by Milton after my first draft taking
> Farzaneh's suggestion.*
> *I do not agree to f seek any legal advice on this issue as this is a
> matter that needs to be agreed by us *
> *I respectfully request you to consider the matter and ask Kurt to bring
> it up at our next meeting .*
> *It is disappointing and frustrating that the comments made by two members
> are so categorically rejected *
> *Regards*
> *Kavouss *
>
>
> On Wed, Jan 23, 2019 at 12:14 AM Marika Konings <marika.konings at icann.org>
> wrote:
>
>> Dear EPDP Team,
>>
>>
>>
>> Please find below the notes, action items and outcomes of today’s EPDP
>> Team meeting.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Caitlin, Berry and Marika
>>
>>
>>
>> =================
>>
>>
>> EPDP Team Meeting #38
>> Tuesday, 22 January 2019
>> Notes and Action Items
>>
>>
>> *EPDP Team Outcomes:*
>>
>> - Recommendation #3 agreement to leave as is in the Initial Report.
>> EPDP Team to ensure that check is done at the time of access model
>> discussions to ensure that accuracy requirements are not impaired.
>> - Recommendation #14: update language to caveat that this
>> recommendation represents the best thinking of the group based on the
>> analysis to date, but there is an iterative process as this Recommendation
>> will be affected by the finalization of the necessary agreements that would
>> define the roles and responsibilities. Staff support team to review final
>> work product on data elements workbooks to ensure consistency with the
>> tables under this recommendations. Should further guidance become available
>> before finalization of the Final Report, EPDP Team can reconsider.
>>
>>
>> *High-level Notes/Actions:*
>>
>>
>> *Action item #1*: Kurt to draft question for submission to legal
>> committee for Ruth re. what accuracy requirements under GDPR mean and what
>> the impact could/should be on the EPDP Team recommendations.
>>
>>
>> *Action item #2*: City field: EPDP Team to reconsider information
>> provided and viewpoints expressed in relation to publication of city field.
>> Should positions change on the basis of that reconsideration, this should
>> be communicated to the list. In accordance with Stephanie’s formal request,
>> the EPDP Legal Committee will discuss drafting a question regarding the
>> city field to legal counsel.
>>
>>
>> *Action item #3*: Staff support team to put forward proposed revisions
>> to recommendation #14 in line with the agreement that was reached in
>> principle.
>>
>>
>> *Action item #4*: EPDP Team to review general comments and bring to the
>> list which other items need further consideration now, which could be
>> addressed later and which are / may be addressed by other groups.
>>
>>
>> *Action item #5*: Leadership team to review general comments discussion
>> table and put forward a proposal for how each item is to be addressed or
>> should be addressed.
>>
>>
>> *Action item #6*: EPDP Team to commence their review on the draft Final
>> Report as soon as possible.
>>
>>
>> *Questions for ICANN Org from the EPDP Team: *None
>>
>>
>> *Notes & Action items*
>> *These high-level notes are designed to help the EPDP Team navigate
>> through the content of the call and are not meant as a substitute for the
>> transcript and/or recording. The MP3, transcript, and chat are provided
>> separately and are posted on the wiki at: *
>> *https://community.icann.org/x/ZwPVBQ*
>> <https://community.icann.org/x/ZwPVBQ>*.*
>>
>>
>> Proposed Agenda:
>>
>>
>> *1. Roll Call & SOI Updates*
>>
>> - Attendance will be taken from Adobe Connect
>> - Remember to mute your microphones when not speaking and state your
>> name before speaking for transcription purposes.
>> - Please remember to review your SOIs on a regular basis and update
>> as needed. Updates are required to be shared with the EPDP Team.
>>
>>
>> 2. Welcome and Updates from EPDP Team Chair (5 minutes)
>> a. Recap from F2F meeting and next steps
>> b. Review of outstanding action items
>> c. Other updates, if applicable
>>
>>
>>
>> - Thank you for all your efforts and work in Toronto
>> - Make sure to have PCRTs and comment summaries available (see
>> https://community.icann.org/x/U4cWBg)
>> - Please make sure to review emails that have and will be circulated
>> - important to flag by the deadline when items need to be discussed
>> further.
>> - Request to reconsider travel support for Kobe. Will likely be in
>> phase 2. Would require additional budget allocation. General methodology
>> for how GNSO meetings are run is expected to be applied - remote
>> participation will be available.
>> - ARS - is it possible to modify compliance purpose to cover also
>> ARS. Could it be part of accuracy discussion? Need to separate accuracy
>> from data quality (ARS).
>>
>>
>> 3. Continue review of public comments on Initial Report
>> a. Recommendation #3 WHOIS Accuracy – “The EPDP Team
>> recommends that requirements related to the accuracy of registration data
>> under the current ICANN contracts and consensus policies shall not be
>> affected by this policy” (30 minutes)
>> i. Silent review of comments received (see PCRT and
>> discussion table at https://community.icann.org/x/U4cWBg) (5 minutes)
>> ii. Question for team: which concerns merit group discussion?
>> Specifically, do any of the concerns present new information the EPDP Team
>> has not discussed during its formulation of this purpose or recommendation?
>> (20 minutes)
>> iii. Confirmation of agreement reached or next steps to come
>> to agreement (5 minutes)
>>
>>
>>
>> - See SSAC comments. Linked to phase 2. Not intended to change the
>> existing recommendation.
>> - Would it be worth asking Ruth to clarify what accuracy requirements
>> entail under GDPR? Legal committee to consider question on this topic. The
>> group has different interpretations as to what 'accuracy' means under GDPR.
>> Legal advice is not expected to change this recommendation but may help
>> inform future work. Make sure that any question is specific as possible,
>> e.g. Does controller have any responsibilities in relation to accuracy and
>> if so, what would those be?
>> - Consider moving this work to phase 2?
>> - This appears to be a policy issue, not GDPR compliance. Could be
>> dealt with later.
>> - Should EPDP Team evaluate whether existing accuracy procedures
>> comply with GDPR?
>> - The party collecting data must make sure that the data is
>> accurately put into their system. So this is a requirement for the
>> registrars in particularly to ensure that the data - as provided by the
>> data subject - is processed accurately.
>> - Need to ensure that compliance has the ability to do their job -
>> aligns with how recommendation is worded at the moment.
>> - EPDP Team agreement to leave recommendation #3 as is. EPDP Team to
>> ensure that check is done at the time of access model discussions to ensure
>> that accuracy requirements are not impaired.
>>
>>
>> *Action item #1*: WHOIS accuracy - Kurt to draft question for submission
>> to legal committee for Ruth re. what accuracy requirements under GDPR mean
>> and what the impact could/should be on the EPDP Team recommendations.
>>
>>
>>
>> b. Recommendation 9 – Data redaction - City (30 minutes)
>> i. Review of ICANN Org response to question on this topic
>> (see
>> https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001250.html)
>> (5 minutes)
>> ii. Deliberate (20 minutes)
>> iii. Confirmation of agreement reached or next steps to come
>> to agreement (5 minutes)
>>
>>
>>
>> - Initial Report recommended to keep Temp Spec requirements for City
>> which means redaction, with IPC/BC noting that it should be unredacted.
>> - Discussed during F2F meeting with several expressing support for
>> not redacting. ICANN Org information shared re. rationale for redaction.
>> - Response from Org speaks to City and postal code, not specifically
>> city. Combination of city and postal code is what could be problematic, not
>> necessarily just city.
>> - In smaller places, identifying city could be an issue.
>> - See also discussion held by RDS PDP WG on this topic.
>> - Redaction of city is compliant per the Temporary Specification, so
>> why change it now.
>> - Useful field for the reasons of jurisdiction.
>> - Need to assess support across different groups and determine
>> whether consensus exists.
>> - Everyone encouraged to review the information that has been
>> provided on this subject to be able to opine. Consider asking for legal
>> guidance.
>> - Show of hands of those who cannot live with sticking with the
>> temporary specification requirement of redacting city field: IPC, GAC, BC.
>> Document in the Final Report those that cannot live with it.
>>
>>
>> *Action item #2*: City field: EPDP Team to reconsider information
>> provided and viewpoints expressed in relation to publication of city field.
>> Should positions change on the basis of that reconsideration, this should
>> be communicated to the list. In accordance with Stephanie’s formal request,
>> the EPDP Legal Committee will discuss drafting a question regarding the
>> city field to legal counsel.
>>
>> 10 minute break
>>
>>
>> c. Recommendation #14 Responsible Parties (30 minutes)
>> i. Silent review of comments received (see PCRT and
>> discussion table at https://community.icann.org/x/U4cWBg) (5 minutes)
>> ii. Question for team: which concerns merit group discussion?
>> Specifically, do any of the concerns present new information the EPDP Team
>> has not discussed during its formulation of this purpose or recommendation?
>> (20 minutes)
>> iii. Confirmation of agreement reached or next steps to come
>> to agreement (5 minutes)
>>
>>
>>
>> - Comments do not seem to focus on specific changes
>> - Some of this may get determined / dictated by the agreements that
>> are put in place. Should a small team review the table and determine
>> whether any updates need to be made?
>> - What concerns have been raised that need to be addressed in the
>> recommendation?
>> - These are issues where there is disagreement, but it is not a
>> matter of what the parties say but it is a matter law.
>> - Caveat the analysis in some way. Further work is being done. This
>> could help inform those deliberations but it cannot be determinative. Best
>> thinking of the group based on the analysis to date, but there is an
>> iterative process in the form of the necessary agreements which would
>> define the roles and responsibilities. CPH will need to have appropriate
>> agreements with ICANN with regard to data processing.
>> - Will need to review the processing flows after purposes are
>> finalized and data element workbooks have been finished. For example, UDRP
>> is one area where data processing flows are not clear. Note that a small
>> team will meet later today to work on the data elements workbooks. Focus is
>> on post-filing data flows.
>> - Will need to be further detailed in the context of the discussions
>> on the appropriate agreements between CP and ICANN Org.
>> - Path for settling is greater than the time this group has available.
>> - This is dependent on appropriate agreements being in place, as
>> these would inform these recommendations. See also recommendation #13.
>> Obligation for ICANN Org to come to the table.
>> - EPDP Team outcome on recommendation #14: update language to caveat
>> that this recommendation represents the best thinking of the group based on
>> the analysis to date, but there is an iterative process as this
>> Recommendation will be affected by the finalization of the necessary
>> agreements that would define the roles and responsibilities. Staff support
>> team to review final work product on data elements workbooks to ensure
>> consistency with the tables under this recommendations. Should further
>> guidance become available before finalization of the Final Report, EPDP
>> Team can reconsider.
>>
>>
>> *Action item #3*: Staff support team to put forward proposed revisions
>> to recommendation #14 in line with the agreement that was reached in
>> principle.
>>
>>
>> d. General Comments (30 minutes)
>> i. Silent review of comments received (see PCRT and
>> discussion table at https://community.icann.org/x/U4cWBg) (5 minutes)
>> ii. Question for team: which concerns / data elements merit
>> group discussion? Specifically, do any of the concerns / data elements
>> suggested present new information the EPDP Team has not discussed in the
>> context of the Initial Report? (20 minutes)
>> iii. Confirmation of agreement reached or next steps to come
>> to agreement (5 minutes)
>>
>>
>>
>> - Some issues flagged have already been taken up or have been
>> addressed.
>> - Need to further consider Thick WHOIS recommendation as well as P/P
>> recommendation.
>> - Thick WHOIS - may be mixing topics. Group has discussed transfer of
>> data from registrar to registry, but that may not be the same as a registry
>> displaying THICK WHOIS output. EPDP Team should consider disclosure at
>> registry level. What needs to happen in phase 1 and what needs to happen in
>> phase 2, and what is best left to another group? Different options to
>> consider on the table. Consider this topic further in the context of
>> recommendation #5, noting that disclosure is a separate topic from
>> transfer. Or should this be taken up in phase 2?
>> - P/P - additional recommendation as to how to handle P/P
>> registrations: "In the case of a domain name registration where a
>> privacy/proxy service used (e.g. where data associated with a natural
>> person is masked), Registrar MUST return in response to any query full
>> WHOIS data, including the existing proxy/proxy pseudonymized email". What
>> was in the Temporary Specification - need to confirm. Current language is:
>> 2.6. Notwithstanding Sections 2.2, 2.3, 2.4, and 2.5 of this Appendix, in
>> the case of a domain name registration where a privacy/proxy service used
>> (e.g. where data associated with a natural person is masked), Registrar
>> MUST return in response to any query full WHOIS data, including the
>> existing proxy/proxy pseudonymized email. Need to consider this further and
>> implications on GDPR.
>> - Consider deferring these issues to another group to further review.
>> - Consider doing further triage – does it require changes to our
>> Initial Report recommendations, does it require phase two work, or is there
>> another group who is / should deal with this.
>> - Leadership team to review and make a proposal
>> - Look at suggestion of reconsidering definition of gTLD registration
>> data – bring this to the list.
>>
>>
>> *Action item #4*: EPDP Team to review general comments and bring to the
>> list which other items need further consideration now, which could be
>> addressed later and which are / may be addressed by other groups.
>>
>>
>> *Action item #5*: Leadership team to review general comments discussion
>> table and put forward a proposal for how each item is to be addressed or
>> should be addressed.
>>
>>
>> 4. Next steps to get to Final Report (15 minutes)
>> a. See draft Final Report circulated to the mailing list (see
>> https://drive.google.com/a/icann.org/file/d/1E6W-daNTaadOhG5BRlzNJQbrT9MSoKDn/view?usp=sharing
>> )
>> b. Initial thoughts and suggestions
>> c. Process for review (see
>> https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnLL8jw/edit?usp=sharing
>> )
>>
>>
>> *Action item #6*: EPDP Team to commence their review on the draft Final
>> Report as soon as possible.
>>
>>
>> 5. Wrap and confirm next meeting to be scheduled for
>> Thursday, 24 January 2019 at 14.00 UTC (5 minutes)
>> a. Confirm action items
>> b. Confirm questions for ICANN Org, if any
>>
>>
>>
>>
>>
>>
>>
>> *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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses_gnso&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=Cg5uQf0yAfw-qlFZ0WNBfsLmmtBNUiH0SuI6Vg-gXBQ&e=> and
>> visiting the GNSO Newcomer pages
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gnso.icann.org_files_gnso_presentations_policy-2Defforts.htm-23newcomers&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=tT-E2RoAucUb3pfL9zmlbRdq1sytaEf765KOEkBVCjk&e=>. *
>>
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190125/34d43a6f/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list