Daria, For your example, the Replacement Value looks to apply with the use of the “contact-uri”, which I assume is associated with replacement of the “email” property. For the “fn” and the “org” properties, the Removal Method is best since the redaction extension is meant to be an explicit redaction signal to the client in place of using placeholder text. You could register one or more redaction reasons or use custom redaction reasons to describe the reason in the redaction extension in place of using the reason as placeholder text.
Hopefully, this helps. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Daria Sydorenko <daria.sydorenko=40namecheap....@dmarc.ietf.org> Date: Thursday, June 26, 2025 at 9:10 AM To: James Gould <jgo...@verisign.com>, "marc.blanc...@viagenie.ca" <marc.blanc...@viagenie.ca>, "regext@ietf.org" <regext@ietf.org> Cc: "ksenia.chupr...@namecheap.com" <ksenia.chupr...@namecheap.com> Subject: [EXTERNAL] Re: [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 James, I went through your answers. Thank you for the detailed responses. I have a comment about q. #1: 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? We have the following use case within our RDAP: we utilize the Privacy service. When a user enables our privacy service, we use redaction in the RDAP response as shown below: "vcardArray": [ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Redacted for Privacy Purposes"], ["org", {}, "text", "Privacy service provided by Withheld for Privacy ehf"], ["adr", { "cc": "IS" }, "text", ["", "", "Kalkofnsvegur 2", "Reykjavik", "Capital Region", "101", ""]], ["tel", { "type": ["voice"] }, "uri", "tel:+354.4212434"], ["tel", { "type": ["fax"] }, "uri", "fax:"], ["contact-uri", {}, "uri", "https://www.spaceship.com/domains/whois/contact/?d=domain.com";] ] ] r *The user chooses if the email should be replaced with the contact form or an anonymized email. This approach complies with section 9.2.5 of ICANN's Registration Data Policy, which states: "For Registered Names using an Affiliated or Accredited Privacy or Proxy service, Registrar and Registry Operator MUST Publish the full Registration Data of the Privacy or Proxy Service, which MAY also include the existing privacy or proxy pseudonymized email." Following the policy, we don't remove the fields but replace them with the Registration Data of the Privacy Service that we use. Given this, we believe that our approach is the 'Replacement Value' Method for all fields. Do we need to list each replaced field individually in the redacted member, applying specific logic for each one? As I see, for fn, for example, we should use postPath child member, while for contact-uri, prePath and replacementPath will be more suitable. Is there any option to reference the whole object in the "redacted" member using the 'Replacement Value' method (for our use case) to simplify RDAP output? Will be looking forward to your reply. _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 06/25/2025 9:28 PM EEST Gould, James <jgould=40verisign....@dmarc.ietf.org> 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. Hi, My feedback is embedded below, prefixed with “JG-“. Let me know if you have any additional questions. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1hGjM6cUqYUuV72czNjwzQyz2fd4LD6rt8ZzsROLPnl6mctvO1fSXieOYzPV1Qzx3-jkabRz9g02FXd4kGuuvxhZKIFvLRn0AyCOkLSm7IzgD531wuvE8HyAEzFAgiZGCK2g5XR_AQH0Sy57kiPPnNQAvD-8yLnC4ankKmAb80cvbElfsjtdiTnKAVPsIMTWi_P13Y0wrFTK84RGUVMs75W9_8kmRnrp4xmvRO6UAsIUQJjmveSeOnm-Jo-fugkqsxkXy304GEbedxBGvSqIz9r7f2epUL5rP2gJY75_6AVU/http%3A%2F%2Fverisigninc.com%2F> From: Daria Sydorenko <daria.sydorenko=40namecheap....@dmarc.ietf.org> Date: Wednesday, June 25, 2025 at 11:59 AM To: Marc Blanchet <marc.blanc...@viagenie.ca>, "regext@ietf.org" <regext@ietf.org> Cc: Ksenia Chuprina <ksenia.chupr...@namecheap.com> 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 <ksenia.chupr...@namecheap.com> 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 <marc.blanc...@viagenie.ca> 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 <ksenia.chuprina=40namecheap....@dmarc.ietf.org> 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<https://secure-web.cisco.com/1EEnAF9TJadw_HhUmpEHWx0MZXZWqZb4k8GZXNmRMzDOwUe6QvlS2jADrwTAlPn4aQ0sHMf0xWYShuwfV6lzRaSzZGdjt4oT0f8-xBvARf8y12JmAWodSf4pep84nDA-NNYr9ay-du8oNttxnMLIBf8eStRZZ6dyPumeYmRdciKn_M-FcrpogcpftXeHQOqyYrrVWNuDrfa8h0P-2yomR5J9_clfCH9CiBuT_s9xvyi5rWwK2B3v-u_GxMqUwFws5FZL9LFu9RSYr21gPlMHSDAoWSaojZ1KbeW12hAGRIDA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-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<https://secure-web.cisco.com/1EEnAF9TJadw_HhUmpEHWx0MZXZWqZb4k8GZXNmRMzDOwUe6QvlS2jADrwTAlPn4aQ0sHMf0xWYShuwfV6lzRaSzZGdjt4oT0f8-xBvARf8y12JmAWodSf4pep84nDA-NNYr9ay-du8oNttxnMLIBf8eStRZZ6dyPumeYmRdciKn_M-FcrpogcpftXeHQOqyYrrVWNuDrfa8h0P-2yomR5J9_clfCH9CiBuT_s9xvyi5rWwK2B3v-u_GxMqUwFws5FZL9LFu9RSYr21gPlMHSDAoWSaojZ1KbeW12hAGRIDA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-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<https://secure-web.cisco.com/1EEnAF9TJadw_HhUmpEHWx0MZXZWqZb4k8GZXNmRMzDOwUe6QvlS2jADrwTAlPn4aQ0sHMf0xWYShuwfV6lzRaSzZGdjt4oT0f8-xBvARf8y12JmAWodSf4pep84nDA-NNYr9ay-du8oNttxnMLIBf8eStRZZ6dyPumeYmRdciKn_M-FcrpogcpftXeHQOqyYrrVWNuDrfa8h0P-2yomR5J9_clfCH9CiBuT_s9xvyi5rWwK2B3v-u_GxMqUwFws5FZL9LFu9RSYr21gPlMHSDAoWSaojZ1KbeW12hAGRIDA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-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<https://secure-web.cisco.com/1EEnAF9TJadw_HhUmpEHWx0MZXZWqZb4k8GZXNmRMzDOwUe6QvlS2jADrwTAlPn4aQ0sHMf0xWYShuwfV6lzRaSzZGdjt4oT0f8-xBvARf8y12JmAWodSf4pep84nDA-NNYr9ay-du8oNttxnMLIBf8eStRZZ6dyPumeYmRdciKn_M-FcrpogcpftXeHQOqyYrrVWNuDrfa8h0P-2yomR5J9_clfCH9CiBuT_s9xvyi5rWwK2B3v-u_GxMqUwFws5FZL9LFu9RSYr21gPlMHSDAoWSaojZ1KbeW12hAGRIDA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-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 -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
