Hi, My feedback is embedded below, prefixed with “JG-“. Let me know if you have any additional questions.
Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Daria Sydorenko <[email protected]> Date: Wednesday, June 25, 2025 at 11:59 AM To: Marc Blanchet <[email protected]>, "[email protected]" <[email protected]> Cc: Ksenia Chuprina <[email protected]> Subject: [EXTERNAL] [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello team, Could you please let us know if any information is already available to cover our question? We are looking forward to a response from you. _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 05/27/2025 2:33 PM EEST Ksenia Chuprina <[email protected]> wrote: Hello Marc, Thank you for passing my query to the working group. We appreciate your efforts on RDAP, and if it helps you can use our Spaceship RDAP Production environment with .ote domain names for tests, e.g. https://rdap.spaceship.com/domain/xn--20001013-01-75066601--1726844587268632-17da086aa.work.ote<https://secure-web.cisco.com/1wAdhc-t6b80KYiMW36BTSlLCmW---iTyvBcNggJl2mU2j1eZyC4utpleca_1foyJCebEy4vQhhn-8534cBwPXtnSvrp7Opop9WAd3ATJ68EwLroOjRREg6Nnttv1bDe7C8Uu9hYhEKYg5AlZ4nxcKGIALvZVY6nK6FsBu7UVun3wVmtaXwvWf4RN5ArDidUHwwrQ1cMTA6XpKreC7SDudNb__umuFSce8ZQmlRcBiFp7q4CTx3Gz8aN-TgRjk6XrwlSIBBwVdbmu2LuU5_BiqlElCSou0-46spDfYVAmeJ8/https%3A%2F%2Frdap.spaceship.com%2Fdomain%2Fxn--20001013-01-75066601--1726844587268632-17da086aa.work.ote> This is the only approach we can currently suggest. And just for you to know, we have not yet upgraded to the RDAP 2024 version. Should that suit you, let me know, and I will provide a few more .ote domain names. Have a wonderful one ahead! On 05/26/2025 3:45 PM EEST Marc Blanchet <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Hello, I’ll let the wg respond to your query. I’m writing to you because I’m the author of the RDAP Browser mobile app (iOS and Android). I’m working on a major update of both versions which will include Redacted. (I was one pushing for a better solution than just random strings saying no data here). If you have any test server/infrastructure that would contain the real data but in a non-production mode, and interested in interop testing, let’s talk! Regards, Marc. Le 22 mai 2025 à 13:10, Ksenia Chuprina <[email protected]> a écrit : Greetings Team, I am a Business Analyst at Namecheap Inc, a Domain Registrar. We are currently working on the upgrade of our RDAP to the version 2024 and we have questions about entities redaction. We reached ICANN, but they have forwarded us to you. Hope you can help us with that: 1. We mainly use the redaction by ‘Replacement Value' method. We checked that for the ‘Removal' method we can reference the whole object in the 'redacted' member if all fields of that object are removed (e.g. Tech contact). Can we do the same for the ‘Replacement Value’ method or do we need to reference each redacted field separately in the ‘redacted’ member? JG- The reason that the “Removal Method” can reference a single redaction element for a removed object is the redaction of the parent object applies to all children as well. I’m not exactly sure what the child members are being replaced with (e.g., proxy data, placeholder text). The “Replacement Value Method” is a more specific redaction feature that is meant to resolve to a useful value (e.g., anonymized email, web form). Can you describe what form of replacement that you’re planning on using? 1. Many child members of the ‘redacted’ member are marked as ‘optional’ in the RFC9537<https://secure-web.cisco.com/1K-p06XuKlGkEPkvNLd0CFFLUUAXdJvZoYGuBloQH1ApcgRqEbkz8m8SpOaM6pGOYMixPweHL9Z57jsGmMpRUGGWCyxEfc2aQOh5NmeeCB_DG9ZdQmnbkBsqbJrt2IqCI5e8CSwdL3hglT8F-EVT1SUESR9il3jDd_IvAacOc9cPEfi9w9JNEHFK5KdrrH4_n4FQ07bBvuC6PDhT242rqiRiQ8R_n2fJu7sswGT-n1WRKMnCFNn6k-Ddwb-Jq9Q3Hih9judqi7GBZOX0HRJIIHkNZr26lnJbBk6Him5VKwYA/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9537.html%23name-redaction-by-removal-method>. Is it totally up to us whether to include them or not, or do they become obligatory on a certain condition? In particular, we have doubts about ‘postPath’ and ‘method’ members when using the ‘Replacement Value’ redaction method, but it would be best to know the approach to all members. JG – The only required member is the “name” member and the “method” member, where the “method” member has an implied default value of “removal” when not provided. There are some normative MUST and MUST NOTs defined in the RFC that covers specific use cases, but in general it’s flexible to work for your redaction needs. 1. In the ‘name’ member of the ‘redacted’ member, can we always use the ‘description’ field or is it a must to use the ‘type’ field for the registered redacted names? JG – There is no normative requirement to use the “type” field when there is a registered redacted name, but I do recommend it. The client will get more meaning with the use of a pre-registered value as opposed to a custom value with the “description” field. If the latter is the case, where do we find the ‘registered redacted names’? Are those the Values in the Appendix E of the RDAP Response Profile<https://secure-web.cisco.com/1OIQ1ZznOOEGtb9TYBIlQtBSByoZ5yuTqoBGyrcwX5aUcLxkij4yFFgKevwKXbnXdNshnMAhX6VjrhSyLZidXV8R1TDjkUDFuax_2LVzwsw10fR3oTtKku871_UijCmMb8ESUs1gPIqR2dyDZah20jOPkaE5gLYnMxOJdosUnL_1zoXDcagAAU3ac9WdQTKPBzuq9JDmGM13RCSdSkV87_S48CV85ZnlI00XB4aQOtozWu9HJSFxifNa12mUUdua0HtfJLiDIglguaUCDNZlyMFNbl0TIrf4fU6EfXNSRK1g/https%3A%2F%2Fvalidator.rdap.org%2Fspecs%2Fgtld%2F2024-02%2Frdap-response-profile-21feb24-en.pdf%23page%3D16>? JG – You can find the registered redacted names in the RDAP JSON Values IANA Registry (https://www.iana.org/assignments/rdap-json-values) using the Type value of “redacted name”. These were registered when the RDAP Response Profile was completed. FYI We checked that we will have more contact sets/fields than covered in the Appendix, and also such values as ‘Registrant contact’ to reference the whole object are absent in it, that’s why we are wondering if we can always stick to the ‘description’ field. JG-As noted earlier, the use of the “type” field is better than using the “description” field, since the client will be able to better understand its meaning. If you see the need for more generic registered redacted name values, then you can go through the process defined in Section 10.2 of RFC 9083 to register them in the RDAP JSON Values registry (https://www.iana.org/assignments/rdap-json-values) referencing the Type “redacted name”. My recommendation is to leverage the “type” field for all registered redacted name values, register any new generic redacted name in the RDAP JSON Values registry (https://www.iana.org/assignments/rdap-json-values) and use the “type” field, and finally use the “description” field for custom redacted name values. 1. Do we get this right that we can choose either ‘type’ or ‘description’ field In the reason member of the ‘redacted’ member, or are they both required? Where can we find the list of ‘registered redacted reasons’? We saw Registries using ‘Server policy’ as a reason, is that okay to use that by default? JG – Yes, the same pattern is followed for the “reason” member as with the “name” member, where it’s better to use a “type” field if there is a registered redacted reason and use the “description” field otherwise. There are currently no registered redacted reason values in the RDAP JSON Values registry (https://www.iana.org/assignments/rdap-json-values), which can be addressed by going through the process defined in Section 10.2 of RFC 9083 to register them in the RDAP JSON Values registry referencing the Type “redacted reason”. The registration of the “Server policy” redacted reason makes logical sense. Looking forward to hearing from you. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected] Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
