Hi James, Thank you a lot for the prompt reply and detailed explanations. We have no further questions.
Have a great week! > On 07/25/2025 8:16 PM EEST Gould, James <[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. > ******************** > > Hi, > > It looks like you are replacing the contacts with proxy data. Are you > completely replacing the contact data and not attempting to signal what > contact data exists but redacted? This was not exactly the purpose of the > replacement value method since it’s meant to be used on a per member basis. > If you’re replacing the entire contact due to redaction with a privacy > contact, then the replacement value method could be used at the level of the > contact to provide that signal. If you are physically removing the contact > due to redaction, then you could use the removal method. I recommend > registering the contact-level “redacted name” values in the RDAP JSON Values > registry to support this for each of your contacts, such as below where I > don't include the use of two double quotes in the CSV values of Description: > > Value, Type, Description, Registrant, Reference,Registant Name,Registrant > Contact Information > Registrant Contact,redacted name,“Redacted entity object class, with > “registrant” role. The “removal” or “replacementValue” redacted “path” > member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is > “$.entities[?(@.roles[0]=='registrant')]”,Namecheap,<Namecheap contact > information> > Tech Contact,redacted name,“Redacted entity object class, with “technical” > role. The “removal” or “replacementValue” redacted “path” member JSONPath > for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is > “$.entities[?(@.roles[0]=='technical')]”,Namecheap,<Namecheap contact > information> > Admin Contact,redacted name,“Redacted entity object class, with > “administrative” role. The “removal” or “replacementValue” redacted “path” > member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is > “$.entities[?(@.roles[0]=='administrative')]”,Namecheap,<Namecheap contact > information> > Billing Contact,redacted name,“Redacted entity object class, with “billing” > role. The “removal” or “replacementValue” redacted “path” member JSONPath > for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is > “$.entities[?(@.roles[0]=='billing')],Namecheap,<Namecheap contact > information> > > > Thanks, > > > -- > > JG > > > > James Gould > Fellow Engineer > applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > http://verisigninc.com/ > > From: Ksenia Chuprina <[email protected]> > Date: Friday, July 25, 2025 at 11:50 AM > To: James Gould <[email protected]>, > "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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. > Hi James, > > Thank you for the prompt reply! > > We will then be waiting for your opinion regarding usage our privacy contact > for 'Replacement' (questions 1,2). > > I've checked that the RFC doesn't specify what value we must use for > replacement, it just tells 'The Redaction by Replacement Value Method is when > a redacted field is not removed but its value is replaced with a different > value', so hope our method works. > > Looking forward to hearing from you. > On 07/25/2025 6:21 PM EEST Gould, James <[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. > Hi, > > The Replacement Value Method is not meant to replace the value with > placeholder text. You can use the Removal Method as the signal for > redaction. > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > http://secure-web.cisco.com/1B5dPbXH836nxJ1LZLoYBY0CqMuQCbGkHsoX-tthVcpec-ZEBBy5hvIhsu9DvlZ-I8gVbDA0iIEyKrZmUULXoDh_gG_v7x7csHzLwCghuK2dObVyJgGWP9qPtWMurF2hYRriPi88rNk7aB0LGlI0pnjGrwhEXp-w9pI6BV9HQW1VKq4hWz6bfOIESyakmamOPdF5Zu5BwMjHNolT2oHRr9iK8kz395wRsOGXUmY_bQM9fA8xDzN-uP7MGYvpQUM1xKtDZW935z70Q65YvBQ451wyhFVmnHDqoy9KpgiybPEw/http://verisigninc.com/ > > From: Ksenia Chuprina <[email protected]> > Date: Friday, July 25, 2025 at 11:08 AM > To: James Gould <[email protected]>, > "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Cc: Daria Sydorenko <[email protected]> > 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. > Hi James, > Apologies for following up again so soon. > > I just wanted to kindly ask if you could prioritize reviewing the third > question regarding domain handle redaction, the others can wait a bit longer > on our side. > > Let me repeat it here: > 3) for domain handle, can we also use ‘Replacement’ method, by which we mean > replacing the handle value with a text ‘redacted for privacy’? > 3.1) in general, what methods can be used for redaction of this element? > > We’d really appreciate your reply on that specific point as soon as possible, > as we’re aiming to get the team started right away. > > With the deadline a month away, we want to make sure we stay on track and > don’t lose any time. > > Looking forward to your reply. > On 07/24/2025 1:38 PM EEST Ksenia Chuprina <[email protected]> > wrote: > > > Hi James, > > Just following up on my previous message, have you had a chance to review my > questions about contacts redaction? > > We want to clarify all uncertainties so that we have enough time for > implementation till the August deadline. > > Looking forward to your reply. > On 07/10/2025 6:12 PM EEST Ksenia Chuprina <[email protected]> > wrote: > > > Hello James, > > Thank you very much for the detailed explanations. We deeply appreciate your > help. > > Let me clarify once more how we want to implement redaction of contact > entities. > > We provide our customers with an option to turn on/off a Privacy tool for > domains, which helps them to open/hide their contact information in RDAP. > > If a customer decides to enable the tool, we hide their contacts in RDAP, > i.e. replace all customer’s data with the following values of the Privacy > service contact, including also contact handle: > ___________________________ > > handle: ID of Privacy service contact set associated with domain (not real ID > of the client’s contact entity); unique for each contact entity and each > domain. > > fn: Redacted for Privacy > org: Privacy service provided by Withheld for Privacy ehf > address: > IS > Kalkofnsvegur 2 > Reykjavik > Capital Region > 101 > tel: +354.4212434 > fax: don’t pay attention to it being empty; the output is being worked on; we > preliminary plan to come up with the value to hide client’s real fax > > email: anonymous email, which redirects correspondence to the customer’s real > email address > (This is the case that we want to address now. We have one more case with > contact form, but we think we got how to deal with it from your explanations, > thanks!) > ___________________________ > > So these are not redaction signals, this is the contact info which belongs to > our > https://secure-web.cisco.com/1tz9G45aBiPmibL0IE-Ie8sYIibUvLDRkxbXRofQj35bHvZ1aU1WfPbnMZKxZRPNC8NCH5bTPEZFNPu66TkYImtuSXdD-0IemhKmUo3DJ5Zj6wbzjDSMkF34_oxyJK37WumeJ9SXRp3tjbtQLAjs3vnbgqc2aCLWFsEAzxWogm6BpwZBGFQr-Tr1CmCWQc58aVQ0LhqaKOJlDjjt15V1lnU0x4zgDGWluL4ie3OWHtQXrsw45_M3qkd4xqEvuLkbGqJa0cBikEgnhgW1JLshKQ9epKuzyocQkC-KypzKzus4/https://www.spaceship.com/domains/domain-name-privacy/. > We are obliged to show it according to point > https://secure-web.cisco.com/1GmOQhMPO_kzG-Ud0000ajkc98SwiU3K-N2PiCFEiUf2989tE1BKNl2qSC5lScLLeKazP9ydKSXP_WNT2vBsGYC1573aCDsPdbv4hMJOwH3KhUinoGKoaWI_dHKVbtmkGM3swWnzEqaeiuKBjTZRnMzNaXSrKN172uZIZsP3u8cKW4kWa4rRM1ZpEdcpqfni0OZxjK-1BW47ifXDMZe08vWKRfRnnASgZHXdTynSylm9WEQrIA47XlRRsb23LbC8nw_IB1ZtA2ml1z_05ROL5TctLpxwDX2-gBeqvrpSlK-0/https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy#domain-name-registration-data, > and we promise to show the data exactly this way to our customers. > > We want to avoid removing that info from RDAP output due to the reasons > above. We intend to leave it as it is, and we’d like to specify the following > with you to adjust our current approach so that it conforms with RFC9537: > > 1) could you confirm that what we are doing (replacing customer’s data with > Privacy tool contacts) is Redaction by Replacement method > (https://secure-web.cisco.com/12em8HkrBbLEegt_QRn7uLeKiNU-r0kZFGcmK169ZtqwF_hNv3j5HwaBxd_hKywacNyQ-tZDu9pAlldI7t8fJYmonpLUqXR4hl-4UXd68Ac04xbDmUgK9krzSPIfnPHKXH45C9xNGOEDXp050QbSE2BEkybxP1anQZHA98tNY9dLSVAEYQx9zujleiOJA_PAVCWPi6-uTzRNBQOD-rXIQHhKoQH93x7zQeJ9fsJYaScSATBFl47Hz4XvoDFAkTIPKLMChQdamvxBAe_l7JE2FyNQS2CrsVHbdXvNkg-jAxco/https://www.rfc-editor.org/rfc/rfc9537.html#name-redaction-by-replacement-va), > and if it is not, could you explain why and what method it actually is? > > RDAP output example: > https://secure-web.cisco.com/1ysa42S4lPal8eDdgDPQq_fAG7JqF_-wxkdtbyjNzy10HNLiM-IpDuj5hGx109LC3osHUeLZ60lx-pEjfB0JE66dFPfny2-yRoq0RbExgJZWOoDbobFMFSg0HLrcA3-xRKe8E0NVgqIOuIVc_0m_6LZ0uQ-x65zCl4m-XlmqaxziTmj8IFod2VSN3XrWGRT-tDo8qLls-1RVQ6zXCJjSzlsHCiwkgz2Bzy6RBD0gu20_vgQ4XzoqhVCFWX7idSmotR-nAg3g8fhxsUc7oo4pvqILhrqQJCoxNkagTBaUvUY0/https://rdap.spaceship.com/domain/1finechecks.com > > > 2) since we are replacing value of every field in a contact object with > Privacy tool data, can we reference the whole object (e.g. Registrant contact > or Tech contact etc) in the 'redacted' member instead of referencing each > separate field or we cannot? > > For example, like this: > > "redacted": [ > > { > > "name": { > > “description": "registrant entity” > > }, > > "method": "replacementValue", > > } > > ] > > And I also have an additional question to you: > 3) for domain handle, can we also use ‘Replacement’ method, by which we mean > replacing the handle value with a text ‘redacted for privacy’? > 3.1) in general, what methods can be used for redaction of this element? > > Looking forward to hearing from you. > > > On 07/08/2025 7:42 PM EEST Gould, James <[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. > Daria, > > Sorry for the delayed response. My responses are embedded below prefixed > with “JG-“. > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > http://secure-web.cisco.com/1uoQk3dQRjpdRRB6izGP9m2sgqQraZTQiabbVtRvUpi7W0i_Il2MO7H5Bj2EzswJWbiSas5f4Moa0fAkAOrlK-SHa8-XYZ0gXxdwTCYcyOLXKhD0yVVcUWD5QfSrkFqkg_Js5_jmQEy1f8ueTy_A_pLsGRBe5z1ZLIdQctUMHm2d7WuwP7cSfvsRugUfq0WAJTXvTQ1B6pvga_pFz06Pml8gTzX5-TNyx6o1ziKCeUIcEfAaISIcmNfc_ldboyeci8QwRLrj8mU1SlCPMmzzud5H8CNxjo1tCOcViggStEyc/http://verisigninc.com/ > > From: Daria Sydorenko <[email protected]> > Date: Friday, June 27, 2025 at 4:50 AM > To: James Gould <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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. > Got it, thank you so much. > > For clarity, are you redacting all properties of the contacts, but including > a proxy replacement for the e-mail property? > Yes. You can check the following output as an example: > https://secure-web.cisco.com/184Z5-cGSc1VoBYbz8zwT31osTi3emrFfajBZPCraTbUeIWIJSWqIuvDQQecTaQRyKWIh357_YKtlhAVHrIA5sSpGIwUnSU1WsYmCjARtVOrlc-1nXl-HT1bMu89Ocsk17avqA8TJdjuzAUxHxSGdN6z6pJUroo4iPf932vVjVapAUwQmhL4Fl6BYw62vnUt1jvfGFOp652Qkz5Ic7yV-WMurhXFOo3Cejk1wNHBeokMioDRkRXFO89RATC9mqzPcFDUNtbsNxem7VI9Jg84IniYymMz33T9BPG2IkcpwwUA/https://rdap.spaceship.com/domain/srgrthrsthsrh.sbs > > JG-I see that with the RDAP response that you’re currently using placeholder > text to provide a redaction signal for the “fn” and “org” members and using > replacement for the “email” member with the “contact-uri” member. The “adr” > and the “tel” “voice” member is provided. I’m unclear why the “tel” “fax” > member is being returned since it provides no value. This applies to all > roles (“registrant”, “administrative”, “technical”, and “billing”). Based on > this, the redaction would include the entries at a minimum: > > "redacted": [ > { > "name" : { > "type": "Registrant Name" > }, > "method": "removal" > }, > { > "name" : { > "type": "Registrant Organization" > }, > "method": "removal" > }, > { > "name" : { > "type": "Registrant Email" > }, > "replacementPath": > "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]", > "method": "replacementValue" > }, > { > "name" : { > "description": "Administrative Name" > }, > "method": "removal" > }, > { > "name" : { > "description": "Administrative Organization" > }, > "method": "removal" > }, > { > "name" : { > "description": "Administrative Email" > }, > "replacementPath": > "$.entities[?(@.roles[1]=='administrative')].vcardArray[1][?(@[0]=='contact-uri')]", > "method": "replacementValue" > }, > { > "name" : { > "description": "Tech Name" > }, > "method": "removal" > }, > { > "name" : { > "description": "Tech Organization" > }, > "method": "removal" > }, > { > "name" : { > "description": "Tech Email" > }, > "replacementPath": > "$.entities[?(@.roles[2]=='technical')].vcardArray[1][?(@[0]=='contact-uri')]", > "method": "replacementValue" > }, > { > "name" : { > "description": "Billing Name" > }, > "method": "removal" > }, > { > "name" : { > "description": "Billing Organization" > }, > "method": "removal" > }, > { > "name" : { > "description": "Billing Email" > }, > "replacementPath": > "$.entities[?(@.roles[3]=='billing')].vcardArray[1][?(@[0]=='contact-uri')]", > "method": "replacementValue" > } > ] > > JG-The redaction name values of “Administrative Name”, “Administrative > Organization”, “Administrative Email”, “Tech Name”, “Tech Organization”, > “Tech Email”, “Billing Name”, “Billing Organization”, and “Billing Email” > could be changed to use the “type” instead of the “description” once they’re > registered in the RDAP JSON Values Registry. > > So, did I understand correctly that we should treat our redaction method > (placing privacy service registration data instead of user PI) as a Removal > Method since it doesn't provide any useful information but acts as a > placeholder, yes? > > JG-If you were only returning the “email” member via replacement with the > “contact-uri” member for all contact roles, then you would do something like > the following: > > "redacted":[ > { > "name":{ > "description":"Registrant Contact" > }, > "method":"removal" > }, > { > "name":{ > "type":"Registrant Email" > }, > > "replacementPath":"$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]", > "method":"replacementValue" > }, > { > "name":{ > "description":"Administrative Contact" > }, > "method":"removal" > }, > { > "name":{ > "description":"Administrative Email" > }, > > "replacementPath":"$.entities[?(@.roles[1]=='administrative')].vcardArray[1][?(@[0]=='contact-uri')]", > "method":"replacementValue" > }, > { > "name":{ > "description":"Tech Contact" > }, > "method":"removal" > }, > { > "name":{ > "description":"Tech Email" > }, > > "replacementPath":"$.entities[?(@.roles[2]=='technical')].vcardArray[1][?(@[0]=='contact-uri')]", > "method":"replacementValue" > }, > { > "name":{ > "description":"Billing Contact" > }, > "method":"removal" > }, > { > "name":{ > "description":"Billing Email" > }, > > "replacementPath":"$.entities[?(@.roles[3]=='billing')].vcardArray[1][?(@[0]=='contact-uri')]", > "method":"replacementValue" > } > ] > > JG-You would remove the use of placeholder text values outside of the > “redacted” member, which is one of the goals of the redaction extension. > > And we can scale this logic to other cases. For example, for GDPR, we can > redact all properties of the contact so they have the value "REDACTED" except > for the email address, which has contact-uri. > > In these cases, are we ok (in terms of RFCs) to call this redaction method > Removal? > Will it not be a mistake that the contact object is still present in the RDAP > output? > Do you think we should include any JSONPath (none of the "prePath", > "postPath", or "replacementPath" looks fully relevant in this case for me)? > > JG-My recommendation is to include the use of the “replacementPath”, since it > specifies what is replacing the “email” member due to redaction. > _____________ > > Best regards, > Daria Sydorenko > Product Coordinator - Domains Compliance > Namecheap/Spaceship > > On 06/26/2025 6:22 PM EEST Gould, James > <[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. > Daria, > > For clarity, are you redacting all properties of the contacts, but including > a proxy replacement for the e-mail property? In that case, it would be > overkill to include all the contact properties individually that are using > the Removal Method. What I’m thinking is that it would be best to signal the > client that the contacts by type are being redacted via the Removal Method > and include the redaction of the contact email individually via the > Replacement Method in the redaction extension. So, for the 4 contacts roles, > there would be four object-level removal redaction entries and four > field-level replacement redaction entries. I don’t believe it will make a > difference whether there is a single entity with four roles or multiple > entities with a single role. The following redacted names could be > registered to use the name “type” field instead of the name “description” > field: > > • “Registrant Contact” > • “Administrative Contact” > • “Tech Contact” > • “Billing Contact” > • “Administrative Email” > • “Billing Email” > > The “Registrant Email” and “Tech Email” redacted names are already > registered. > > This is my initial thought, but there could be other approaches from the > working group to cover this use case. > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > http://secure-web.cisco.com/17zKPxSmnFoOpNLSiJklTuXrUQ2GOkdIvYkuYH_g-k2lIEBZUQ15Rzu5Nv9TIMMqLpwVrmA31oavl-9kwgDpL0G-hyhedjFNtmiBM7dvHdHuCbNaC43Sg9OxiQ938E33ueqlxH0Q9L4-J6gHBitUAFIQ6loTiNp3wQNZM9i_5ulxBFYmaCtQdzDzHBt4UfEVKXP8-zOabDey_hc3c4OPfCRNBPJikE7I0ELiJWXuYaZMVqgqZt4JnXb251pDk9QU64Ht9EfY0E-FLEQ4baFQni_VDObYgueov8YrDlnCJ4eE/http://verisigninc.com/ > > From: Daria Sydorenko <[email protected]> > Date: Thursday, June 26, 2025 at 10:42 AM > To: James Gould <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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. > I would also like to add some context and clarify my questions > > We gather 4 contacts for all gTLDs: Registrant, Technical, Administrative, > Billing, and show all four in our RDAP. > When the user adds the Privacy service for their domain name, there can be 2 > main cases: > > 1) RDAP output has one entity with four roles. > 2) RDAP output has several entities with their own roles (but the redacted > values are the same for each entity). > > My questions are: > - FOR CASE 2: > can we reference the whole object (e.g. Registrant contact, Administrative > contact, etc.) in the redacted member? > - FOR CASE 1: > can we reference the whole object only once if it has more than 1 role? > > - If no, can we reference the same field only once if it has different roles > when such a field is redacted for all roles (given that the reason is the > same - privacy service)? > For example, in both use cases, we can redact registrant, admin, billing, and > technical email using the same contact-uri with the same link. Can we > reference this in the "redacted" member only once, or do we need to add each > redacted field separately? > _____________ > > Best regards, > Daria Sydorenko > Product Coordinator - Domains Compliance > Namecheap/Spaceship > > On 06/26/2025 4:09 PM EEST Daria Sydorenko <[email protected]> > wrote: > > > 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";] > ] > ] > *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 > <[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. > Hi, > > My feedback is embedded below, prefixed with “JG-“. Let me know if you have > any additional questions. > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > http://secure-web.cisco.com/1haCjyo7cl-91kyQ3VqfMki8w3kzHOAPlPtm9QAiIdvwjwA9FRm_pn0xE8O2nvC85ySBtrEY2TIFUivKRpmef_rDqItysXxAQe4kZ_whseY_AtF7Xc62MCHyuXitoYG8771RzjLXCOkNnLmyWtPT4AZ_OBV4wFX5BEn8i_gqWW2s4PHiJLHMQJisrZwm6yJpcdqZoUIU0Jv7Nt8G3qIn2bsnx7HUSGUzDDwhbTSu89QLuaLZjfPlxK13R6O31c23dsMG5b7mA1G5xPv7ApCfJkUdjlGFbzdCYaTTjcUKe2QM/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://secure-web.cisco.com/1wAdhc-t6b80KYiMW36BTSlLCmW---iTyvBcNggJl2mU2j1eZyC4utpleca_1foyJCebEy4vQhhn-8534cBwPXtnSvrp7Opop9WAd3ATJ68EwLroOjRREg6Nnttv1bDe7C8Uu9hYhEKYg5AlZ4nxcKGIALvZVY6nK6FsBu7UVun3wVmtaXwvWf4RN5ArDidUHwwrQ1cMTA6XpKreC7SDudNb__umuFSce8ZQmlRcBiFp7q4CTx3Gz8aN-TgRjk6XrwlSIBBwVdbmu2LuU5_BiqlElCSou0-46spDfYVAmeJ8/https://rdap.spaceship.com/domain/xn--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? > 2. Many child members of the ‘redacted’ member are marked as ‘optional’ in > the > https://secure-web.cisco.com/1K-p06XuKlGkEPkvNLd0CFFLUUAXdJvZoYGuBloQH1ApcgRqEbkz8m8SpOaM6pGOYMixPweHL9Z57jsGmMpRUGGWCyxEfc2aQOh5NmeeCB_DG9ZdQmnbkBsqbJrt2IqCI5e8CSwdL3hglT8F-EVT1SUESR9il3jDd_IvAacOc9cPEfi9w9JNEHFK5KdrrH4_n4FQ07bBvuC6PDhT242rqiRiQ8R_n2fJu7sswGT-n1WRKMnCFNn6k-Ddwb-Jq9Q3Hih9judqi7GBZOX0HRJIIHkNZr26lnJbBk6Him5VKwYA/https://www.rfc-editor.org/rfc/rfc9537.html#name-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. > 3. 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 > https://secure-web.cisco.com/1OIQ1ZznOOEGtb9TYBIlQtBSByoZ5yuTqoBGyrcwX5aUcLxkij4yFFgKevwKXbnXdNshnMAhX6VjrhSyLZidXV8R1TDjkUDFuax_2LVzwsw10fR3oTtKku871_UijCmMb8ESUs1gPIqR2dyDZah20jOPkaE5gLYnMxOJdosUnL_1zoXDcagAAU3ac9WdQTKPBzuq9JDmGM13RCSdSkV87_S48CV85ZnlI00XB4aQOtozWu9HJSFxifNa12mUUdua0HtfJLiDIglguaUCDNZlyMFNbl0TIrf4fU6EfXNSRK1g/https://validator.rdap.org/specs/gtld/2024-02/rdap-response-profile-21feb24-en.pdf#page=16? > JG – You can find the registered redacted names in the RDAP JSON Values IANA > Registry > (https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/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://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/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://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https://www.iana.org/assignments/rdap-json-values) > and use the “type” field, and finally use the “description” field for custom > redacted name values. > 4. 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://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/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. > > Best regards, > Ksenia Chuprina > Business Analyst > BA&P Department > Namecheap Inc. > > Best regards, > Ksenia Chuprina > Business Analyst > BA&P Department > Namecheap Inc. > > Best regards, > Ksenia Chuprina > Business Analyst > BA&P Department > Namecheap Inc. > > Best regards, > Ksenia Chuprina > Business Analyst > BA&P Department > Namecheap Inc. Best regards, Ksenia Chuprina Business AnalystBA&P Department Namecheap Inc. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
