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

Wed Oct 16 16:06:13 UTC 2019

Correct.   The policy need not be changed since it is MAY language.

The purpose of this exercise is to clarify both the law and the B+B memo which have been discussed in this forum.

Data protection law will impact ICANN and all of us in the community.  It is important that our actions and policies are based on proper understanding of what is allowed.  It is certainly fine for someone to take a more conservative path based on their own needs.  But when we insist that specific policy must be set because certain actions are unlawful, when in fact they can be lawfully performed, we do ourselves and our community a disservice.

I'm looking forward to further discussion later today.

/marksv 

-----Original Message-----
From: Luc SEUFER <lseufer at namespace.com> 
Sent: Wednesday, October 16, 2019 7:55 AM
To: Mark Svancarek (CELA) <marksv at microsoft.com>; Rubens Kuhl <rubensk at nic.br>; irt.regdatapolicy at icann.org
Subject: Re: [IRT.RegDataPolicy] Legal clarification regarding publication of TC data

So just to be clear. The current wording of the policy fits both opinion, right?
Those who trust that GDPR allows to collect and publish the tech contact details via the registrant and who may or may not offer this service and those who believes GDPR does not leave room to do so.

Luc

On 15/10/2019, 20:07, "IRT.RegDataPolicy on behalf of Mark Svancarek (CELA) via IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org on behalf of irt.regdatapolicy at icann.org> wrote:

    	" The person wishing such publication of technical contact can go to a registrar that provides that and request it; there is nothing in the RegData Policy as it's now preventing that. What there is not, reflecting EPDP policy guidance, is something to oblige a registrar to do so, exactly due to the many complexities that can't be easily factored into policy, like how many reseller levels there are in that registration chain, which jurisdictions are involved etc."

    I agree with you: the person wishing such publication of technical contact should be able to go to a registrar that provides that, request it, and have that request honored.
    I also agree with you: a registrar is not obliged to offer such a service.

    Please reread my original email.  The reason I have asked for legal clarification is because it was previously asserted that a person wishing such publication effectively COULD NOT do it under GDPR if the request was initiated by the RNH because a registrar could not lawfully confirm the lawfulness of the request, an assertion that I believed false (as I mention above).
    If I am understanding the opinion, the number of levels isn't an issue.  If there is any debate about that, I can get more clarity from Hintze.

    /marksv

    -----Original Message-----
    From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> On Behalf Of Rubens Kuhl
    Sent: Tuesday, October 15, 2019 10:51 AM
    To: irt.regdatapolicy at icann.org
    Subject: Re: [IRT.RegDataPolicy] Legal clarification regarding publication of TC data

    > On 15 Oct 2019, at 14:30, Mark Svancarek (CELA) <marksv at microsoft.com> wrote:
    > 
    > 	" AFAIK, privacy regulations are about having an use case and then finding the adequate processing for it, not the other way around..."
    > 	" 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."
    > 
    > Rubens, I think you are missing the point.  We are discussing how to enable a technical contact who wishes their contact information to be freely published.  The example is a sample use case for someone who finds a need to contact the technical contact whose data has been freely published for the purpose of fixing a website.  Perhaps we should have used a different example, say reporting a missing AAAA record? The fact that someone would access the freely published contact information has nothing to do with your concerns above.

    The person wishing such publication of technical contact can go to a registrar that provides that and request it; there is nothing in the RegData Policy as it's now preventing that. What there is not, reflecting EPDP policy guidance, is something to oblige a registrar to do so, exactly due to the many complexities that can't be easily factored into policy, like how many reseller levels there are in that registration chain, which jurisdictions are involved etc. 

    BTW, the missing AAAA record is also not a reason to reach the domain technical contact; the DNS provider of a domain can be different from the domain technical contact. Keeping the microsoft.com example, the SOA DNS record of the domain indicates who to reach out to regarding DNS zone contents:
    host -t soa microsoft.com
    microsoft.com has SOA record ns1.msft.net. msnhst.microsoft.com. 2019101505 7200 600 2419200 3600

    In this case, msnhst at microsoft.com. And this was done with a simple DNS query. 

    I'm pretty sure that market demand will make the ones requesting it and the ones offering it to meet and do business. 

    Rubens

    _______________________________________________
    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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870901741&sdata=%2Ffd4fswd589Zh6pDD7WJTDMPoJzCwpQubvV%2F%2BSjVn9s%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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870901741&sdata=dhw3IJ53nY6KAjJzc6JzrEd2InvENliaR5Dvp7j85Bc%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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870901741&sdata=kK%2FICrFbuOjdjL2RraTqekgz8JfTRGSXJYpTvnUK8Ls%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 del
     ivery altogether (e.g., for a vacation), and so on.
    _______________________________________________
    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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870901741&sdata=%2Ffd4fswd589Zh6pDD7WJTDMPoJzCwpQubvV%2F%2BSjVn9s%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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870911734&sdata=Ra19%2FtyLsGlK3lz3Xzgro0pooJnnOHXOybR3J0XQDDY%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%7C907c67073cfc4d6fd81908d75248c890%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637068344870911734&sdata=K8YZYGkN%2FlEqJpXZqNMnhAkDlev6aSIG3i96yHz0JJQ%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.