[IRT.RegDataPolicy] Legal clarification regarding publication of TC data

Tue Oct 15 17:11:57 UTC 2019

> On 15 Oct 2019, at 13:58, Mark Svancarek (CELA) <marksv at microsoft.com> wrote:
> 
> Don't worry, Rubens, they've made a distinction between websites and domain names.  (Do a search on "website" in the doc and hopefully that will be more clear.)
> 
> If the specific use case ["I want to use the domain name tech contact to report a web site issue"] is not compelling to you, just replace it with any domain name technical other use case which feels more appropriate.  

AFAIK, privacy regulations are about having an use case and then finding the adequate processing for it, not the other way around... 

> 
> FWIW, I was in a situation more than once where I needed content from a broken website and I used the domain name tech contact to get it fixed; I don't see why requiring me to go to the RIR is any more appropriate or convenient.  But that's not what we're discussing here.

This looks the old "just because" type of argument that has been found not to be convincing to DPAs. I'm sure many uses have happened in the past, but we are implementing the ones mapped by the RegData EPDP Phase 1. 

The fact is regarding websites that there is already contact information available elsewhere, triggering the minimisation principle making not usable as legal basis. And since this mailing list is archived, this reference can easily become an exhibit at a DPA fine on someone. 

> 
> Does that help?

Perhaps some CPs might find it helpful and use in their risk assessment; I don't. 

Rubens

> 
> -----Original Message-----
> From: Rubens Kuhl <rubensk at nic.br> 
> Sent: Monday, October 14, 2019 17:39
> To: Mark Svancarek (CELA) <marksv at microsoft.com>
> Cc: irt.regdatapolicy at icann.org
> Subject: Re: [IRT.RegDataPolicy] Legal clarification regarding publication of TC data
> 
> 
> Mark,
> 
> At first glance, this analysis seems to conflate domains with websites. The technical contact for a website is already published by the RIRs, and the interest of having such contact available to be informed of issues is already fulfilled by that information. For instance, https://nam06.safelinks.protection.outlook.com/?url=www.microsoft.com&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696223742&sdata=H5QmtP25LfjNhxHIG1OK88jp9INogxzjBn4Hvp53fLc%3D&reserved=0 resolves in my corner of the net to 184.51.132.196 ; the RIRs publish Akamai's (CDN under contract to serve https://nam06.safelinks.protection.outlook.com/?url=www.microsoft.com&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696223742&sdata=H5QmtP25LfjNhxHIG1OK88jp9INogxzjBn4Hvp53fLc%3D&reserved=0) contact information for that IP address, and if I have an issue with that website, I can reach out to them. 
> 
> 
> NetRange:       184.50.0.0 - 184.51.255.255
> CIDR:           184.50.0.0/15
> NetName:        AKAMAI
> NetHandle:      NET-184-50-0-0-1
> Parent:         NET184 (NET-184-0-0-0-0)
> NetType:        Direct Allocation
> OriginAS:       
> Organization:   Akamai Technologies, Inc. (AKAMAI)
> RegDate:        2009-10-22
> Updated:        2012-03-02
> Ref:            https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F184.50.0.0&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696223742&sdata=gNgLmrk0IyodGsYfZm8NC7r9B%2FBmkZczaKnHIqbs9M0%3D&reserved=0
> 
> 
> 
> OrgName:        Akamai Technologies, Inc.
> OrgId:          AKAMAI
> Address:        150 Broadway
> City:           Cambridge
> StateProv:      MA
> PostalCode:     02142
> Country:        US
> RegDate:        1999-01-21
> Updated:        2019-05-29
> Ref:            https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fentity%2FAKAMAI&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696223742&sdata=TaCZteZZGY9Pqjl2lSSaSp5u0XSAXRQ8pl4IWOHkZo0%3D&reserved=0
> 
> 
> OrgTechHandle: SJS98-ARIN
> OrgTechName:   Schecter, Steven Jay
> OrgTechPhone:  +1-617-274-7134 
> OrgTechEmail:  ip-admin at akamai.com
> OrgTechRef:    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fentity%2FSJS98-ARIN&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=x9oX8%2BYfj1up4deluK0eT6TFA3ell4n0kywm9i0p1xU%3D&reserved=0
> 
> OrgTechHandle: IPADM11-ARIN
> OrgTechName:   ipadmin
> OrgTechPhone:  +1-617-444-0017 
> OrgTechEmail:  ip-admin at akamai.com
> OrgTechRef:    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fentity%2FIPADM11-ARIN&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=dYH%2BvZW7oEejmQ0ldMeTidHUDPR5wxru8kMgedHr2cw%3D&reserved=0
> 
> OrgAbuseHandle: NUS-ARIN
> OrgAbuseName:   NOC United States
> OrgAbusePhone:  +1-617-444-2535 
> OrgAbuseEmail:  abuse at akamai.com
> OrgAbuseRef:    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fentity%2FNUS-ARIN&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=MzMINkxwephVDw7ohzZRBHGvI%2FujCfOOMsxCtJMKPfk%3D&reserved=0
> 
> OrgTechHandle: YKS-ARIN
> OrgTechName:   Yeung, Kam Sze 
> OrgTechPhone:  +852-22718527 
> OrgTechEmail:  ip-admin at akamai.com
> OrgTechRef:    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fentity%2FYKS-ARIN&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=Le99QCeEIUwVrL8uW6%2Buh%2Fc3yCecbGG%2BpJ7YVFqsXsI%3D&reserved=0
> 
> 
> Considering this kind of misunderstanding, I don't see how the IRT could rely on the other parts... perhaps the contractor would be amenable to rectify the legal opinion ? 
> 
> 
> 
> Rubens
> 
> 
> 
> 
> 
> 
> 
>> On 14 Oct 2019, at 21:15, Mark Svancarek (CELA) via IRT.RegDataPolicy <irt.regdatapolicy at icann.org> wrote:
>> 
>> Dear Registration Data Policy IRT team:
>> 
>> You may recall that several weeks ago we discussed the publication of the Technical Contact fields in the case where RNH has requested publication.  At that time, there was concern about the lawful mechanism for collecting TC consent for the publication.  Section 8.2.9 and 8.3.2 in the document linked below reflect the discussion on this topic.
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1OuZT7xL5wuV1ynVmpVNxFycU93gvPlvbzx_g9lXCYCw%2Fedit%3Fpli%3D1&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=c2RJS9gGZvNIk2kVBYpyzq2GBubSdds5L5qQnwG2k3A%3D&reserved=0 [docs.google.com]
>> 
>> Since it seemed unlikely to me that there would be no lawful way to process the data of a party who desires it to be processed, I secured outside counsel [hintzelaw.com] [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhintzelaw.com%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=uJtRkzKnYaXhf3gziS0y7tLqBODdnc4SDscqVDGVZd0%3D&reserved=0] to analyze the scenario and provide feedback.  I am pleased to share this legal opinion now with the IRT team.
>> 
>> In summary, per Hintze there are two lawful mechanisms for publication:
>> 	• 6.1(a) – Consent
>> 	• 6.1(f) – Legitimate Interest
>> 
>> Hintze notes that Article 14 requires the data controller to notify the TC that they have received personal data from another party, and that this notice provides the opportunity to perform multiple functions:
>> 	• Present TC with information regarding personal data in general and publication in particular
>> 	• Allow TC to correct their contact information
>> 	• Allow TC to change their contact information to remove personal data
>> 	• Allow TC to submit or decline to submit their consent for publication should the registrar prefer to use consent as a basis rather than legitimate interest
>> 
>> This clarification should remove remaining implementation concerns regarding the EPDP Phase 1 implementation of the policy recommendations.  I look forward to discussing in our upcoming calls and at ICANN 66 later this month.
>> 
>> Mark Svancarek
>> 
>> 
>> <HL Memo re Publication of TC info 20191003.docx>_______________________________________________
>> IRT.RegDataPolicy mailing list
>> IRT.RegDataPolicy at icann.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Firt.regdatapolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=8N6H8LK8ncfd8oP53hcSkf%2Fh6IPI9Dsg5rPSl3p5aWk%3D&reserved=0
>> 
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=c45MLpxdJyB0DsHYuOiHIUns24rGRSDQZSRWVEzc3jQ%3D&reserved=0) and the website Terms of Service (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C06186df166934bf61fd608d75108227f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066967696233736&sdata=ZfiODq3RzRiLxR%2BDdKmRRkH4aGGaH5wOybR7TVbJ6L8%3D&reserved=0). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
> 