[Gnso-epdp-team] EPDP Recommendation 11 - email list discussion
Theo Geurts
gtheo at xs4all.nl
Thu Jan 24 13:22:01 UTC 2019
Thanks Alan,
Regarding waivers, I think we need to figure out what their actual use is?
Back in the day, the 95/46 directive was implemented differently across
Europe, as such a bit messy.
But this is no longer the case, the data retention directive has been
invalidated and the GDPR has replaced the 95/46 directive.
Best,
Theo Geurts CIPP/E
On 24-1-2019 13:50, Alan Woods wrote:
> Hey all,
>
> To perhaps make my last email a bit more 'actionable' I wish to put a
> suggestion as to the potential wording of an updated recommendation.
> NOTE: it's not an easy task, as the point is that we have not yet been
> armed with adequate data to create a wholly considered retention
> period that will allow for ICANN to insist upon a retention period,
> for certain data elements, for a justifiable and reasonable period of
> time. therefore the recommendation is a bit "hedging our bets" somehow:
>
> To be clear, due to speed with which we are moving, this is tabled as
> to kick off the *discussion/drafting*. I have not run this by even my
> teammates in the RYSG and I am under no illusions that this is the
> 'final' text - merely a suggested path.
>
> *Recommendation 7 *
> *
> *
> *1) The EPDP team recommends that ICANN, as soon as is
> practicable, undertakes a review of all its active process and
> procedures so as to identify and document the instances in which
> personal data is requested from a registrar, outside of the normal
> retention period of the 'life of the registration'. Identified
> retention periods, for specific data elements should be then
> documented and be relied upon to establish, the required relevant
> and specific, minimum data retention expectations for registrars. *
> *
> *
> *2) In the interim, the ePDP has recognized that the Transfer
> Dispute Resolution Policy (“TDRP”) has been identified as one such
> process. The ePDP team therefore recommends that ICANN should
> direct registrars to retain only those data elements as deemed
> necessary for the purposes of the TDRP, for a period of one year
> following the life of the registration. This retention is grounded
> on the stated policy stipulation within the TDRP, that claims
> under the policy may only be raised for a period of 12 months
> after the alleged breach **(FN: see TDRP section 2.2)** of the
> Transfer Policy (FN: see Section 1.15 of TDRP). *
> *
> *
> *3) The ePDP recognizes that Contracted Parties may have needs or
> requirements for longer retention periods in line with local law
> or other requirements. The ePDP recommends that nothing in this
> recommendation, or in separate ICANN mandated policy, should
> prohibited contracted parties from setting their own
> limitation periods beyond that which is expected in ICANN policy.
> Similarly, should local law prevent retention for the period of
> one year, the ePDP recommends that there are waiver procedures in
> place that can address such situations.*
>
>
> NOTE: the waiver procedure is a pet peeve of mine. It make no legal
> sense to me that should a single registry / registrar can prove that a
> law local or otherwise is incompatible with a retention period, that
> ICANN then continues, having actual notice of an incompatibility,
> enforces that retention period against every other contracted party
> who may be similarly subject to that law, until that party makes a
> separate and full application for a waiver. I appreciate that ICANN
> cannot possibly assess jurisdiction of applicability of laws for
> individual CPs, however the process should not be obtuse as to ignore
> it;s own precedent. I don't know if it is in our power to do so,
> however perhaps we should also recommend that any successful waiver
> application process should provide a reasonable period of time whereby
> other CPs may 'join' themselves to a waiver upon presentation of
> sufficient proof of being subject to a particular law or
> requirement that grounded the original application [a fast track
> waiver process so to speak].
>
>
>
>
>
>
>
> Donuts Inc. <http://donuts.domains>
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------------------------------------------------
> The Victorians,
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
> <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc>
> <https://www.linkedin.com/company/donuts-inc>
>
>
> Please NOTE: This electronic message, including any attachments, may
> include privileged, confidential and/or inside information owned by
> Donuts Inc. . Any distribution or use of this communication by anyone
> other than the intended recipient(s) is strictly prohibited and may be
> unlawful. If you are not the intended recipient, please notify the
> sender by replying to this message and then delete it from your
> system. Thank you.
>
>
>
> On Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <gtheo at xs4all.nl
> <mailto:gtheo at xs4all.nl>> wrote:
>
> Thanks, Alan,
>
> From my point of view, your observations are all accurate
> including the registrar ones.
>
> And yes you cannot pick a random number for retention. There is a
> purpose, you balance it, and then you get your period for
> retention. Your purpose and how you balanced it are part of your
> documentation to meet the requirement of Art 5.2. Though usually,
> you cover this process through Art 35.
>
> Theo
> On 23-1-2019 15:38, Alan Woods wrote:
>> Dear all, (noted these are my own musings and my registry
>> colleagues may have additional / different thoughts and comments)
>>
>> *1) Retention period of 1 year *
>> Can we be clear that where data is retained for 1 year, and such
>> an extra retention period is stated as being for use under the
>> TDRP, than retained data may *_ONLY_* be used for that purpose
>> (See the RYSG comment). Based upon this recommendation, should a
>> Registrar use the retained data for any other purpose, the will
>> be doing so under their own controllership stem (Hence why the
>> clarification in the NOTE is exceptionally important.)
>>
>> To be even clearer, ICANN would *NOT* be able to use the retained
>> data for any other purpose other than the TDRP under the current
>> recommendation. This is the core of what the EDPB have repeatedly
>> told ICANN, you can't just arbitrarily pick a retention period,
>> the retention period just be reasoned and the use of that data
>> must be grounded to that reason. The EDPB will be equally as
>> upset about setting a retention period based on one process,then
>> using data for something wholly unrelated to that process.
>>
>> Should we persist I see the issue is as follows:
>>
>> ICANN (Compliance or otherwise) does not hold the data
>> themselves, and this data will be requested from the registrar.
>> This disclosure request will state the reason as X purpose;
>> unless the stated purpose is for in furtherance of the TDRP, a
>> registrar should (read MUST) decline to disclose, as the
>> disclosure is incompatible with the stated reason for retention
>> (i.e. the TDRP)
>>
>> Only ICANN, have the knowledge of why they require retention for
>> specific processes and procedures. They must provide the base
>> policy reason as to why they require, in the contract, a
>> retention period. The TDRP is a good single example, but it is
>> one single example and ICANN, should then need it for any other
>> reason, must tell the ePDP what, why and for how long the data is
>> necessary.
>>
>>
>> 2) R*etention of additional data elements *
>> *
>> *
>> *I would believe the minimal data elements must be retained, and
>> only then related to the specific purpose for the retention. *
>>
>> I do not agree with Trang's assessment of the necessity for
>> billing contacts and in particular the interpretation of
>> "requires a registrar to receive a reasonable assurance of
>> payment prior to activating a domain registration." In this
>> instance the proof of assurance should not, considering data
>> protection, rise to the actual provision of actual billing data
>> but would more functionally refer to, in a normal
>> business sense, assurances that the registrar remains solvent and
>> this does not rise to an ICANN expectation that the
>> registrant ultimately pays (that's the registrar's business) !
>>
>> Re the other elements noted - I would quickly note the following:
>>
>> * Billing contacts - I defer to my registrar colleagues friends
>> here but ICANN does not ever bill registrants. Should a
>> registrar fail and registrations are transferred, then the
>> gaining registrar will need to establish contact again and
>> discern should the registrant wish to continue the
>> relationship with the Registrar. I would opine that this is
>> achieved via registrant contact and a private contract
>> between registrar and registrant. Frankly it has nothing to
>> do with ICANN and is none of their data processing business.
>>
>> * (RAA 3.4.1.5) the name, postal address, e-mail address, and
>> voice telephone number provided by the customer of any
>> privacy service or licensee of any proxy registration
>> service, in each case, offered or made available by Registrar
>> or its Affiliates in connection with each registration.
>> * Full Contact Information for Privacy Proxy Registrations
>>
>> For both the above, again I defer to my registrar colleagues,
>> but again, this data is currently completely remote from
>> ICANN's sphere of influence. The registrant makes a private
>> contract with a P&P provider. Such a contract will have
>> stipulations in the event of a failure of the P&P provider.
>> Use of such providers is at the risk of the registrant, and
>> ICANN cannot interfere here. IF a P&P gets sunk, the
>> registrant will need to deal with their choice and claim
>> relief under their contract etc. - it may be messy but ICANN
>> cannot claim to have a right to this underlying data, as
>> their influence extends to only the data of the registrant
>> (which in this instance will be presented as the P&P holder).
>> ICANN may claim further power via appropriate policy
>> development perhaps but regardless, surely this is a matter
>> for the PPSAI.
>>
>> * Full Contact Information for Registrants who have Consented
>> to Full Display -This is a matter for an assessment of what
>> data is needed for the reason basing the retention. i.e. what
>> data is need currently for performance of the TDRP - nothing
>> else. Again ICANN should identify and justify the data
>> elements necessary for this. The ePDP cannot be expected to
>> do this for ICANN.
>>
>> * (Data Retention Specification 1.1.7.) Types of domain name
>> services purchased for use in connection with the Registration
>> * (Data Retention Specification 1.1.8.) To the extent collected
>> by Registrar, "card on file," current period third party
>> transaction number, or other recurring payment data.
>> * (Data Retention Specification 1.2.1) Information regarding
>> the means and source of payment reasonably necessary for the
>> Registrar to process the Registration transaction, or a
>> transaction number provided by a third party payment processor;
>> * (Data Retention Specification 1.2.2) Log files, billing
>> records and, to the extent collection and maintenance of such
>> records is commercially practicable or consistent with
>> industry-wide generally accepted standard practices within
>> the industries in which Registrar operates, other records
>> containing communications source and destination information,
>> including, depending on the method of transmission and
>> without limitation: (1) Source IP address, HTTP headers, (2)
>> the telephone, text, or fax number; and (3) email address,
>> Skype handle, or instant messaging identifier, associated
>> with communications between Registrar and the registrant
>> about the Registration; and
>> * (Data Retention Specification 1.2.3 ) Log files and, to the
>> extent collection and maintenance of such records is
>> commercially practicable or consistent with industry-wide
>> generally accepted standard practices within the industries
>> in which Registrar operates, other records associated with
>> the Registration containing dates, times, and time zones of
>> communications and sessions, including initial registration.
>>
>> I'm minded to wholly defer this particular ... issue... to
>> our registrar colleagues. But to the Casual observer none of
>> this data is in ICANN's remit to retain. This is all part of
>> the private contract with the registrant and registrar and
>> ICANN has no legal claim, basis or expectation to this data.
>> If ICANN believes that they have a right to this data, then
>> it is for them to assert it and justify why they need to
>> mandate something as the harvesting and retention to data
>> wholly unrelated to the registration of a domain name. Let us
>> provide a simple example If a registrant doesn't pay the
>> registrar for a domain (declined card or other), ICANN will
>> still likely get paid because that is the contract they have
>> with the CPs; the registry will still get paid as that is the
>> contract with the registrar. Neither registry or registrar
>> may, nor should go after the registrant for such a payment,
>> as we have no right to do so as that is not the intended
>> legal nature of our relationship. Therefore why would ICANN
>> have a right to the information regarding cards on file or
>> client communications?
>>
>> * (RAA 3.4.2.1) the submission date and time, and the content,
>> of all registration data (including updates) submitted in
>> electronic form to the Registry Operator(s);
>> * (RAA 3.4.2.2) all written communications constituting
>> registration applications, confirmations, modifications, or
>> terminations and related correspondence with Registered Name
>> Holders, including registration contracts;
>> * (RAA 3.4.2.3) records of the accounts of all Registered Name
>> Holders with Registrar.
>>
>> These are all data that ICANN could possibly mandate. But
>> that being said, this all seems aimed at litigation. These
>> are elements that a Registrar, in its sole controllership as
>> a business, would be crazy not to retain for the purposes of
>> litigation impending or actual etc. Regardless, in truth I
>> can't see how ICANN would EVER have such data disclosed to
>> them unless by court order or equivalent where there is a
>> dispute between Rr and ICANN.
>>
>> I think we need to be clear as to necessity here and IMHO, a lot
>> of these elements are simply overreach.
>>
>> Kind regards,
>>
>> Alan
>>
>>
>>
>>
>>
>> Donuts Inc. <http://donuts.domains>
>> Alan Woods
>> Senior Compliance & Policy Manager, Donuts Inc.
>> ------------------------------------------------------------------------
>> The Victorians,
>> 15-18 Earlsfort Terrace
>> Dublin 2, County Dublin
>> Ireland
>>
>> <https://www.facebook.com/donutstlds>
>> <https://twitter.com/DonutsInc>
>> <https://www.linkedin.com/company/donuts-inc>
>>
>>
>> Please NOTE: This electronic message, including any attachments,
>> may include privileged, confidential and/or inside information
>> owned by Donuts Inc. . Any distribution or use of this
>> communication by anyone other than the intended recipient(s) is
>> strictly prohibited and may be unlawful. If you are not the
>> intended recipient, please notify the sender by replying to this
>> message and then delete it from your system. Thank you.
>>
>>
>> On Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen
>> <trang.nguyen at icann.org <mailto:trang.nguyen at icann.org>> wrote:
>>
>> Dear All,
>>
>> Regarding data retention, ICANN org has previously identified
>> a question and some areas that we wanted to flag for the EPDP
>> Team, which we sent to the mailing list on 22 December 2018
>> (https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html).
>> We are flagging them here again for the EPDP Team’s
>> consideration/discussion as you work to finalize the
>> recommendation.
>>
>> The question/flags are:
>>
>> 1. There are several data elements that are currently
>> required to be retained, but are not addressed in the
>> Initial Report. Should the retention obligation for these
>> data elements remain or be discontinued?
>> 2. If billing and payment-related data is no longer required
>> to be collected, retained, and (with respect to billing
>> contact data) escrowed, this could impact continuity of
>> service to registrants and availability of this data in
>> the event of a payment dispute or related investigation.
>> ICANN org also notes that the ICANN Registrar
>> Accreditation Policy
>> <https://www.icann.org/resources/pages/policy-statement-2012-02-25-en>
>> requires a registrar to receive a reasonable assurance of
>> payment prior to activating a domain registration.
>>
>> Data elements currently required to be collected, but are not
>> addressed in the Initial Report include:
>>
>> * Billing/Other Contact ID (where available)
>> * Billing/Other Contact Name (where available)
>> * Billing/Other Contact Street (where available)
>> * Billing/Other Contact City (where available)
>> * Billing/Other Contact State/Province (where available)
>> * Billing/Other Contact Postal Code (where available)
>> * Billing/Other Contact Country (where available)
>> * Billing/Other Contact Email (where available)
>> * Billing/Other Contact Phone (where available)
>> * Billing/Other Contact Fax (where available)
>> * (RAA 3.4.1.5) the name, postal address, e-mail address,
>> and voice telephone number provided by the customer of
>> any privacy service or licensee of any proxy registration
>> service, in each case, offered or made available by
>> Registrar or its Affiliates in connection with each
>> registration.
>> * Full Contact Information for Privacy Proxy Registrations
>> * Full Contact Information for Registrants who have
>> Consented to Full Display
>> * (Data Retention Specification 1.1.7.) Types of domain
>> name services purchased for use in connection with the
>> Registration
>> * (Data Retention Specification 1.1.8.) To the extent
>> collected by Registrar, "card on file," current period
>> third party transaction number, or other recurring
>> payment data.
>> * (Data Retention Specification 1.2.1) Information
>> regarding the means and source of payment reasonably
>> necessary for the Registrar to process the Registration
>> transaction, or a transaction number provided by a third
>> party payment processor;
>> * (Data Retention Specification 1.2.2) Log files, billing
>> records and, to the extent collection and maintenance of
>> such records is commercially practicable or consistent
>> with industry-wide generally accepted standard practices
>> within the industries in which Registrar operates, other
>> records containing communications source and destination
>> information, including, depending on the method of
>> transmission and without limitation: (1) Source IP
>> address, HTTP headers, (2) the telephone, text, or fax
>> number; and (3) email address, Skype handle, or instant
>> messaging identifier, associated with communications
>> between Registrar and the registrant about the
>> Registration; and
>> * (Data Retention Specification 1.2.3 ) Log files and, to
>> the extent collection and maintenance of such records is
>> commercially practicable or consistent with industry-wide
>> generally accepted standard practices within the
>> industries in which Registrar operates, other records
>> associated with the Registration containing dates, times,
>> and time zones of communications and sessions, including
>> initial registration.
>> * (RAA 3.4.2.1) the submission date and time, and the
>> content, of all registration data (including updates)
>> submitted in electronic form to the Registry Operator(s);
>> * (RAA 3.4.2.2) all written communications constituting
>> registration applications, confirmations, modifications,
>> or terminations and related correspondence with
>> Registered Name Holders, including registration contracts;
>> * (RAA 3.4.2.3) records of the accounts of all Registered
>> Name Holders with Registrar.
>>
>> Best,
>>
>> Dan and Trang
>>
>> ICANN Org Liaisons
>>
>> *From: *Gnso-epdp-team <gnso-epdp-team-bounces at icann.org
>> <mailto:gnso-epdp-team-bounces at icann.org>> on behalf of Kurt
>> Pritz <kurt at kjpritz.com <mailto:kurt at kjpritz.com>>
>> *Date: *Tuesday, January 22, 2019 at 1:20 PM
>> *To: *EPDP <gnso-epdp-team at icann.org
>> <mailto:gnso-epdp-team at icann.org>>
>> *Subject: *[Gnso-epdp-team] EPDP Recommendation 11 - email
>> list discussion
>>
>> Hi Everyone:
>>
>> There were several items (Recommendations) that we agreed to
>> discuss via email with the idea that we could close on them
>> without taking time for discussion in a meeting. This email
>> concerns Recommendation 11, addressing the data retention period.
>>
>> *The current recommendation states:*
>>
>> The EPDP Team recommends that Registrars are required to
>> retain the herein-specified data elements for a period of one
>> year following the life of the registration. This retention
>> period conforms to the specific statute of limitations within
>> the Transfer Dispute Resolution Policy (“TDRP”).
>>
>> *Small Team Discussion*
>>
>> (1)The small team noted that “statute of limitation” as used
>> in the Recommendation was probably an inappropriate use of a
>> legal term of art and should be replaced with more
>> appropriate language. This point is addressed in the proposed
>> updated Recommendation below.
>>
>> (2)Some on the small team advocated for a longer retention
>> period, suggesting that a longer retention period could be
>> anchored in existing ICANN policy requirements or other
>> outside requirements. (The current retention period is
>> anchored is the Transfer DRP as the “tall pole” among all
>> the other purposes for processing registration data.) The
>> updated language below, proposed by small team B, clarifies
>> that the proposed data retention period is for ICANN related
>> requirements and different retention periods may apply as a
>> result of local requirements or circumstances.
>>
>> *Proposed updated language recommendation 11 – data retention*
>>
>> The EPDP Team recommends that: Registrars are required to
>> retain the herein-specified data elements for ICANN-related
>> requirements for a period of one year following the life of
>> registration. This minimum retention period is consistent the
>> requirements of the Transfer Dispute Resolution Procedure,
>> which has the longest retention requirement of any of the
>> enumerated Purposes for Processing Registration Data.
>>
>> Note, Contracted Parties may have needs or requirements for
>> longer retention periods in line with local law or other
>> requirements. This is not prohibited by this language.
>> Similarly, should local law prevent retention for the period
>> of one year, there are waiver procedures in place that can
>> address such situations.
>>
>> *Actions*
>>
>> Those supporting a retention greater than one year generally
>> should submit rationale for such a retention period including
>> related ICANN policy requirements to which this could be
>> anchored. These submissions will be discussed via email.
>>
>> Submit comments for support for the amended Recommendation
>> or requesting edits to the recommendation with rationale.
>>
>> Deadline: Friday, 24 January, additional email discussion
>> might follow depending on responses.
>>
>> Thank you and best regards,
>>
>> Kurt
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>>
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org <mailto: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/20190124/881c2c48/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list