Sorry to be pedantic, but the requirement doesn’t describe a form of redaction. It describes replacement. “Redaction by Replacement” is commonly implemented by obscuring sensitive information with a phrase like “[sensitive information removed]”. As long as the draft makes it clear that text being used to obscure the original value is a real, usable replacement value, then I’d be OK with option 1.
Scott From: regext <regext-boun...@ietf.org> On Behalf Of Gould, James Sent: Friday, March 25, 2022 11:33 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] draft-ietf-regext-rdap-redacted Support for Redaction by Replacement Value Method 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. There was discussion in the ICANN RDAP working group associated with the requirement for the “Registrar MUST publish an email address or a link to a web form for the email value to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address”, based on the IRT.Draft Registration Data Policy (OneDoc). The question for the REGEXT working group is whether replacing a value with another value (e.g., anonymized email) is a form of redaction that needs to be supported in draft-ietf-regext-rdap-redacted. This was discussed with the editors of draft-ietf-regext-rdap-redacted, and we feel this is a form of redaction. Assuming that the first question is yes, replacing a value in the RDAP response is a form of redaction, then there were three options discussed to handle it: 1. Add a third redaction method to section 3 of draft-ietf-regext-rdap-redacted, with the name “Redaction by Replacement Value Method” and with the “method” value “replacementValue” to identify a field that had its value replaced. The concrete example is the use of the anonymized email value. 2. Extend #1 by making the redaction methods extensible with the definition of another JSON Values Registry type value of “redacted method”. The three redaction method type values of “removal” for Redaction by Removal Method, “emptyValue” for Redaction by Empty Value Method, and “replacementValue” for the new Redaction by Replacement Value Method would be initially registered. 3. Rescope draft-ietf-regext-rdap-redacted to cover special handling of RDAP response fields, where redaction is one form of special handling. An IANA registry would define an extensible set of special handling types. In discussing this with the editors of draft-ietf-regext-rdap-redacted, we feel that option #1 (Add a third redaction method) is the best option. We feel that option #1 addresses the concrete issue without unneeded complexity and is flexible enough to address other forms of replacement redaction, such as the use of a privacy proxy that is not the legal contact. The second question for the REGEXT working group is which option is desired to support redaction by replacement. Thanks, -- JG James Gould Fellow Engineer <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 <http://secure-web.cisco.com/1WaisAhHTeg_0GXO0q00hzr10xwgagziMFrgLD6rV10RyiYA--TaCNaqcBUe_xu5jrDNNl55BCz8VmhtcPIVOsOkfqA8cmkvQE0UnstlTRosd14TgH20CpSqIwfU7BoPoDXgUo6Iz9XS6eI_d1BL7yzjReuyU2T2BIA7Cw437Bl3dZg8eII3jEmw7AZb2T-vpYQ8MuvSUCKj_dlPZqjbd4hmBHBmTtLs4OHbM0tfBio5tX_TTeFdqoVeSMwDba9H6/http%3A%2F%2Fverisigninc.com%2F> Verisign.com
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
