[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

[Volker Greimann]

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
> 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.
-- 
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

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/d6732131/attachment.html>