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

["Gould, James" <[e-mail]>]

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

[cid:image001.png@01D8403C.0DF2C8E0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>