Re: [regext] draft-ietf-regext-rdap-redacted Support for Redaction by Replacement Value Method

["Hollenbeck, Scott" <[e-mail]>]

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 <[e-mail]> On Behalf Of Gould, James
Sent: Friday, March 25, 2022 11:33 AM
To: [e-mail]
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/[e-mail]> 
[e-mail]

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