[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

[King, Brian]

That's a good catch, Volker. Thanks.

Perhaps a phased, staggered, or otherwise gradual approach would be best.

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

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> On Behalf Of Volker Greimann
Sent: Thursday, February 27, 2020 4:57 AM
To: irt.regdatapolicy at icann.org
Subject: Re: [IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY


Just bear in mind that even though this may be a simple change for registrars, for all thick registries this would trigger a mass update from all affected registrars who will have to update the domain name records for all sponsored domain names at the registries. That can amount to significant load.

I do agree that having unified language has a value of convenience, but there is an implementation concern to be considered.

Best,

Volker
Am 26.02.2020 um 18:57 schrieb King, Brian via IRT.RegDataPolicy:
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<mailto:IRT.RegDataPolicy at icann.org>

https://mm.icann.org/mailman/listinfo/irt.regdatapolicy<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=ddZcEX2DxbyWbk7PztNodkIJ6cdclu7yHBws9usXdiM&e=>



_______________________________________________

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=_XVVogim2dJ1qRpamWhEti5Be7QeESvtkBvOXPef8S4&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=RJNpzPWhfU2OMnqUbY950YeKh00zi7RTqSEFhsXjGwI&e=>). 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.
--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=_CBUdtjdSE2U-KQliMp2WsEDK3J41mQpU2UrdoSbfSY&e=>

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200227/d58b715a/attachment.html>