Hi James,
Please find my comments embedded below.
Am 19.12.22 um 14:54 schrieb Gould, James:
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?
[PK] Sorry for not being specific enough in my previous remark.
My point was to indicate in the Abstract and Introduction to the
document, that the documents specifies ways of redaction, not only
indentification thereof - in a generic way.
A proposed change to the Abstract:
"This document describes an RDAP extension for specifying ways of
redaction of RDAP responses and explicitly identifying redacted RDAP
response fields, using JSONPath as the default expression language."
I would see similar change to the first paragraph of Introduction section.
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?
[PK] Yes, "prePath" and "postPath" works for me. Do I understand it
right, you'd like to keep "replacementPath" which can come in the same
response with "postPath" in case the previous value was replaced with
empty and the replacement value is under a different path? If yes, than
I'm also fine with that.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
