[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

[King, Brian]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200226/ceb89f2f/attachment.html>