[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

[Theo Geurts]

1 I see not much value in it. I got more hassles with lawyers claiming 
the data is incorrect because they cannot find the company called 
redacted for privacy in a company database/register.

In addition we do not redact the data due to privacy, we redact data due 
to data protection laws.

Redacted due to GDPR makes more sense to me or redacted due to whatever 
data protection law.

We can come up with something better than redacted for privacy right?

2 I guess I never realized that when I put every domain name under our 
management on our privacy protect service I will never have to deal with 
SSAD?

Theo


On 26-2-2020 18:57, King, Brian via IRT.RegDataPolicy wrote:
>
> Hello IRT,
>
> I was personally a bit unclear on where we left this from today’s 
> call, so I wanted to close the loop on list.
>
> Phase 1 left it to implementation to decide what language would be 
> substantially similar to REDACTED FOR PRIVACY, which must be returned 
> where applicable. While I understand we have some hesitation about 
> being too proscriptive, I think there is overriding value in being 
> proscriptive here for two reasons:
>
>  1. There is actually value to implementers in knowing exactly how to
>     treat these fields, as it makes implementation easier and less
>     risky (otherwise how do implementers know if the language they
>     want to use is sufficiently “substantially similar”)?
>  2. Users of RDS data need to know clearly whether a privacy/proxy
>     service is being used, or if the data is redacted by policy
>     (REDACTED BY POLICY might actually be clearer substitute
>     language). RDS users need to know whether to go to SSAD to request
>     redacted data, or to the P/P service to request disclosure under
>     the P/P policy. Ambiguity here not only harms those who need the
>     data, but also those who would receive requests for the underlying
>     data, or compliance complaints about not providing the data when
>     this ambiguity leads to erroneous requests.
>
> Unless I’m missing something, the value of being proscriptive here, 
> and the risk of not being proscriptive, really outweighs the minor 
> convenience to implementers of choosing their own language. Thanks, team.
>
> *Brian J. King *
> Director of Internet Policy and Industry Affairs
>
> T +1 443 761 3726_
> markmonitor.com <http://www.markmonitor.com>_
>
> *MarkMonitor
> *Protecting companies and consumers in a digital world
>
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> 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://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200227/7ab4abef/attachment.html>