Pawel, My responses are embedded below prefixed with "JG2 -".
Thanks, -- 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, 11:44 AM, "Pawel Kowalik" <kowa...@denic.de> wrote: 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. JG2. - Thanks for the clarification and the proposed change. One small language adjustment is to change "ways" to "methods" to better align with the "Redaction Methods" defined in Section 3. The result for the Abstract and the first sentence of the Introduction is: "This document describes an RDAP extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language." This change will be incorporated in draft-ietf-regext-rdap-redacted-11. > 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. JG2 - Yes, the "replacementPath" member needs to remain and can be included with the "postPath" member when an empty value field is replaced with a different field. Changing the "path" member to the "prePath" and "postPath" members will be included in draft-ietf-regext-rdap-redacted-11. Kind Regards, Pawel _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
