RDE (Registrar Data Escrow) specs, verification, data handling
Hello, lately we've received some new warnings in the response e-mails we're receiving from our RDE Agent (IronMountain/NCC) after making a deposit. They seem to indicate that ICANN is starting a stricter verification of the RDE CSV data than what was previously applied, to check compliance with https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf and a new document entitled "Registrar Data Escrow Guidelines" which we've received from NCC but which doesn't seem to be published anywhere online. In this context, we were wondering about some of the involved data handling that seems to be implied by the verification messages, and what other registrars on this list may be doing in this regard. In particular, 1) Do you locally store the data of non-sponsored contact objects referenced by your domains? For thick registries, it is usually perfectly legal for a domain sponsored by registrar A to use a contact sponsored by registrar B, e.g. after a transfer. Thanks to GDPR and other data protection policies, the data of such foreign contact can usually not be inquired by the non-sponsoring registrar, which makes its local storage impossible. Nevertheless, the Escrow guidelines seem to dictate that registrar A's RDE deposits should include the data of registrar B's contact, which in most cases cannot be known by registrar A. Of course, one way to solve this would be to require registrars to only use their own contacts in all of their domains, but this somewhat breaks the relation model between domains and contacts (as obviously intended by the inventors of EPP) as far as its cross-registrar application is concerned. 2) How to you handle domains which are lacking certain contact types? The contact types for which some data is expected in the RDE deposit are still the usual four: registrar, admin, tech, billing. However, some gTLDs are no longer requiring billing contacts thanks to GDPR (they never made much sense in the first place), and even admin and tech are oftentimes no longer required (e.g., CentralNic doesn't seem to enforce admin contacts anymore). If anyone from ICANN is reading this, any input would also be highly appreciated, especially regarding the new document "Registrar Data Escrow Guidelines" which seems to also introduce some new requirements regarding proxy contacts. Generally, this could be a good opportunity to standardize, streamline and modernize the RDE data format, which was so far highly underspecified. Unfortunately, the new documents that popped up recently (see above) are not helping with this issue, on the contrary: they are creating even more uncertainty instead. Best regards, Thomas Corte on behalf of COREhub -- --=== COREhub Technical Support ===------------------------------------- Thomas.Corte@knipp.de Thomas Corte COREhub, IANA ID 15
Hello Thomas, For your questions about specific content requirements in registrar data escrow deposits, I suggest you submit your inquiry to globalSupport@icann.org directly so that it can be properly channeled. As communicated by ICANN to accredited registrars back in June-2022, NCC group has indeed updated their registrar data escrow deposit verification process to cover the requirements from the Registrar Data Escrow Specifications (https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf) and since 1-July-2022, NCC has been including warning messages when the deposit is found to be non-conformant with such requirements. The document available at https://www.icann.org/en/system/files/files/registrar-data-escrow-deposit-ve... may be helpful in providing more details regarding the warning messages provided by NCC Group as a result of their deposit verification process. Hope this helps, --Eduardo A. -----Original Message----- From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of "Thomas Corte (COREhub support) via gtld-tech" <gtld-tech@icann.org> Reply-To: "Thomas Corte (COREhub support)" <Thomas.Corte@knipp.de> Date: Monday, June 20, 2022 at 10:20 AM To: "gtld-tech@icann.org" <gtld-tech@icann.org> Cc: "core-gateway@knipp.de" <core-gateway@knipp.de> Subject: [gtld-tech] RDE (Registrar Data Escrow) specs, verification, data handling Hello, lately we've received some new warnings in the response e-mails we're receiving from our RDE Agent (IronMountain/NCC) after making a deposit. They seem to indicate that ICANN is starting a stricter verification of the RDE CSV data than what was previously applied, to check compliance with https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf and a new document entitled "Registrar Data Escrow Guidelines" which we've received from NCC but which doesn't seem to be published anywhere online. In this context, we were wondering about some of the involved data handling that seems to be implied by the verification messages, and what other registrars on this list may be doing in this regard. In particular, 1) Do you locally store the data of non-sponsored contact objects referenced by your domains? For thick registries, it is usually perfectly legal for a domain sponsored by registrar A to use a contact sponsored by registrar B, e.g. after a transfer. Thanks to GDPR and other data protection policies, the data of such foreign contact can usually not be inquired by the non-sponsoring registrar, which makes its local storage impossible. Nevertheless, the Escrow guidelines seem to dictate that registrar A's RDE deposits should include the data of registrar B's contact, which in most cases cannot be known by registrar A. Of course, one way to solve this would be to require registrars to only use their own contacts in all of their domains, but this somewhat breaks the relation model between domains and contacts (as obviously intended by the inventors of EPP) as far as its cross-registrar application is concerned. 2) How to you handle domains which are lacking certain contact types? The contact types for which some data is expected in the RDE deposit are still the usual four: registrar, admin, tech, billing. However, some gTLDs are no longer requiring billing contacts thanks to GDPR (they never made much sense in the first place), and even admin and tech are oftentimes no longer required (e.g., CentralNic doesn't seem to enforce admin contacts anymore). If anyone from ICANN is reading this, any input would also be highly appreciated, especially regarding the new document "Registrar Data Escrow Guidelines" which seems to also introduce some new requirements regarding proxy contacts. Generally, this could be a good opportunity to standardize, streamline and modernize the RDE data format, which was so far highly underspecified. Unfortunately, the new documents that popped up recently (see above) are not helping with this issue, on the contrary: they are creating even more uncertainty instead. Best regards, Thomas Corte on behalf of COREhub -- --=== COREhub Technical Support ===------------------------------------- Thomas.Corte@knipp.de Thomas Corte COREhub, IANA ID 15 _______________________________________________ gtld-tech mailing list gtld-tech@icann.org https://mm.icann.org/mailman/listinfo/gtld-tech ________________________________________________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.
participants (2)
-
Eduardo Alvarez -
Thomas Corte (COREhub support)