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:[email protected]]

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

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

Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to