Pawel, Thank you again for your review and feedback. I provide answers to your feedback embedded below.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/19/22, 2:43 AM, "Pawel Kowalik" <kowa...@denic.de> wrote: Hi James, Thanks for posting the new version incorporating the changes. I reviewed it and have few comments on that: 1. As the WG consensus seems to be to keep normative language in the form "placeholder text XXXX, MUST NOT be used for redaction" I would recommend to extend Abstract and Introduction accordingly, that the document also specifies allowed methods of RDAP response redaction. JG - Other forms of redaction can be created and used, which can also result in a future update to the draft or RFC. As an example, the new Redaction by Partial Value Method was added in draft-ietf-regext-rdap-redacted-10 to cover a newly raised use case. The proposal to use of placeholder text for redaction drove the initial creation of this draft to define an explicit redaction signal that didn't touch the content of the response body, which is the reason why placeholder text redaction needs to be called out. Do you have a redaction use case that is not effectively covered by the methods defined in the draft that needs to be considered? Have you implemented placeholder text redaction in a way that can't be transitioned to use the redaction extension? 2. The description of "path" member in 4.3 is now correctly describing all the cases for different redaction methods, but due to that it became very complex. I would still reconsider, if it wouldn't be better to have 2 members "preredactedPath" and "redactedPath", which refer to pre-redacted response and redacted response accordingly. Then for different redaction method you would apply: - Redaction By Removal Method: preredactedPath (OPTIONAL, same as path in -10) - Redaction by Empty Value Method: redactedPath (MANDATORY, same as path in -10) - Redaction by Partial Value Method: redactedPath (MANDATORY, same as path in -10) - Redaction by Replacement Value Method: preredactedPath (OPTIONAL, same as path in -10) and redactedPath (MANDATORY, same as replacementPath in -10) I see a clear advantage of this approach that the clients can always use "redactedPath" on the response object without tedious logic depending on redaction method. JG - I agree that embedding the path context (pre or post redaction) into the member names provides a more explicit signal. I would view the members as being mutually exclusive, as reflected by the second sentences of the descriptions below. I don't see any impact on the use of the "replacementPath" member. One variance with what you describe is that the "redactedPath" is only required for the Redaction by Replacement Value Method when the redacted member does exist in the redacted response (e.g., empty instead of removed). How about shortening the member names with some additional normative descriptive language below? "prePath": OPTIONAL JSON expression referencing a redacted JSON field in the pre-redacted response. The "prePath" member MAY be set when the redacted field does not exist in the redacted response for the Redaction by Removal Method (Section 3.1) and the Redaction by Replacement Value Method (Section 3.4). The "prePath" member MUST NOT be set when the "postPath" member is set. "postPath: OPTIONAL JSON expression referencing a redacted JSON field in the redacted (post-redacted) response. The "postPath" member MUST be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4), The "postPath" member MUST NOT be set when the "prePath" member is set. A nuance is that the "postPath" member is required for the Redaction by Replacement Value Method only when the redacted field does exist in the redacted response (e.g., empty instead of removed). The focus of the normative language is whether the redacted field exists in the redacted response, where the list of the methods applies. Is this clear? Kind Regards, Pawel _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
