Pawel, Thank you for the detailed review. I provide responses 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 11/14/22, 12:18 PM, "Pawel Kowalik" <pawel.kowa...@denic.de> wrote: Hi, As an action item after IETF 115 I reviewed draft-ietf-regext-rdap-redacted-09 before WG LC and have the following questions / remarks: Section 3, first paragraph: > Redaction in RDAP can be handled in multiple ways. The use of > placeholder text for the values of the RDAP fields, such as the > placeholder text "XXXX", MUST NOT be used for redaction. A > placeholder text value will not match the format requirements of each > of the RDAP fields and provides an inconsistent and unreliable > redaction signal. Is the normative language adequate here? Firstly, I am not sure if the text can be well understood. Does it mean that use of a fixed placeholder is prohibited, or any placeholder? I can imagine a way of using placeholders, which do not necessarily break the format requirements, therefore the second sentence shall not categorically tell "will not match" as it may not be even true. JG - The use of placeholder values for redaction is prohibited based on the second normative sentence. The normative language is needed to implement the redaction defined by the RDAP extension. I agree that stating "A placeholder text value will not match" is too strong and needs to be changed to "A placeholder text may not match". This will be changed in the next version of the draft. My proposal would be to use SHOULD NOT instead of MUST NOT. It can be useful for the servers willing still to support clients not implementing this extension in the transition period to populate fields with placeholders instead of just empty/missing fields. JG - I understand that there may be a transition period to fully implement the RDAP extension as will be the case of any RDAP extension that standardizes a crosscutting feature like redaction, but weakening the normative language from MUST NOT to SHOULD NOT misses the purpose of the RDAP extension and will result in potentially long running interoperability issues. --- Section 3, second paragraph: The whole paragraph deals with particularities of redacting jCard with some very specific guidelines and examples. Wouldn't it be more and future proof to have a general statement that redacting the data MUST NOT break the underlying data format? The same remark applies then later to 3.2. with normative language for jCard redaction. JG - jCard is currently used in RFC 9083 and the specifics of handling redaction of jCard is an important concept that needs to be covered. The "Redaction by Empty Value Method" is needed because of jCard. I believe the combination of jCard being used in RFC 9083 and the definition of a redaction method to support jCard warrants providing the detail. --- 4.2. "redacted" Member The whole "redacted" member and especially the "path" and "replacementPath" members shall allow the client to recognise parts of the JSON response which have been transformed in the process of redaction. Here some interesting questions: - do the paths refer to the object before or after the redaction? - if the paths refer to the object before the redaction, how should the client be able to interpret the path if not having access to this object, especially the JSONPath may even match multiple paths, e.g. from result and the path the client cannot digest which paths have been really removed? More to that each redaction step is actually transforming the object, so the order of redaction is also relevant in this case. Normalized Paths from JSONPath allow "reversing" the process from the result object if the order of redaction is being held. - if the paths refer to the object after the redaction, likely the path member should be OPTIONAL not not required for redaction by removal or replacement, because in this case the object likely does not exist in the result object JG - The path refers to the object before the redaction for the Redaction by Removal Method, since the RDAP field was removed. In this case the path points to where the RDAP field would have been. The path refers to the object before and after the redaction for the Redaction by Empty Value Method, since the RDAP field exists but has been set to an empty value. The path refers to the object before the redaction for the Redaction by Replacement Value Method, while the replacementPath refers to the object after the redaction, since it points to the replacement JSON field. Right, requiring the path to a non-existent JSON fields in the case of the Redaction by Removal Method and the Redaction by Replacement Value Method consequently requires the client to validate the JSONPath expression using a non-redacted RDAP response,, which the client does not have. Having the JSONPath for where the field would have existed may be useful for a client, but they would need to generate the non-redacted response. I don't oppose setting the "path" to OPTIONAL but with normative language specifying that it MUST be included when the JSON field does exist in the redacted response. Do you agree with this? With Section 5 being not-normative and about processing by the server, the draft should similarly include considerations for processing of the responses by the clients. JG - Yes, Section 5 provides non-normative considerations for the server. Offhand I believe considerations #2 "Validate a JSONPath expression using a non-redacted RDAP response" could be applicable when a client receives a response that includes the "path" expression for the Redaction by Removal Method and the Redaction by Replacement Value Method, per the feedback above, but the client would need to generate a template non-redacted RDAP response based on the "path" expressions. Do you agree with this possible consideration, and do you have any other considerations that should be considered? If there are useful client considerations, they certainly can be added. --- "pathLang" member What is the rationale behind introducing this extension point? Right now the RFC specifies only one language, which is default one. If there will be an additional one I would expect it added by a RFC also answering some questions how to transition from one path language to another. Without any way for the client to express which "pathLang" it would like to get response with, the server would only be able to migrate after all clients support both formats, otherwise risking some clients to break. And if this "pathLang" member is to persist, shouldn't there be IANA registry for allowed values, so that the clients have an ide what to implement? JG - The expression language being stuck with JSONPath was brought up on the list, which resulted in adding the OPTIONAL "pathLang" field. A new JSON Values Registry field value could be added, like "redacted name" and "redacted reason". How about the "redacted expression language" Type with a pre-registration of the Value "jsonpath" and the description "JSON path expression language, as defined in draft-ietf-jsonpath-base"? We would replace draft-ietf-jsonpath-base with the published RFC, which is a normative reference dependency. --- 3.1. Redaction by Removal Method > The Redaction by Removal Method MUST NOT be used to remove a field > using the position in a fixed length array to signal the redacted > field. For example, removal of an individual data field in jCard > [RFC7095] will result in a non-conformant jCard [RFC7095] array > definition. Is the first normative sentence meant to apply to every case, or just the case where removal of such field would render an invalid jCard? I think there is quite legit way or removing whole objects by position in a fixed length array, like "path": "$.entities[0]" which should be still allowed. JG - It's really meant to directly address the jCard use case, but I believe it would apply to all fixed length arrays. Would it help to clarify this more by updating the language to be "using the fixed field position of a fixed length array"? --- 6.2. JSON Values Registry Registry for "redacted name" allows to identify what has been removed without interpreting it from the path member. This is of a great benefit, looking at the difficulties of interpreting the "path" member I mentioned above. JG - Agreed that the registering a new JSON Values Registry Type and pre-registering the "jsonpath" expression language can help as stated above. However, semantically, isn't this registry rather defining the members and objects of RDAP response in a general sense? I mean "Registry Domain ID" means the same no matter if in context of redaction or in context of RDAP response and actually IMHO we should make sure it means the same in any other RDAP context it would be used in the future. IMHO this IANA registry shall be a generic one defining labels to the information pieces in RDAP responses. JG - No, the JSON Values Registry defines the values that can be used for fields, which is applicable here for the valid set of "type" field values used in the redacted "name" and "reason" fields. The same can be done to define the valid field values for the "pathLang" field. The registered Type values of "redacted name", "redacted reason", and potentially the " redacted expression language" will provide the needed isolation with the other typed values in the registry. --- Examples with entity role indexing. The draft has many examples of the kind $.entities[?(@.roles[0]=='registrant')] which might be incorrect if an entity holds multiple roles, as RFC9083 does not specify any particular order of roles in the array and also depending on the roles held by the entity the array might have different length. This means that 'registrant' can be at index 0, but also at index 1. The correct expression would rather be with wildcard index as per 3.5.2. of JSONPath, like this $.entities[?(@.roles[*]=='registrant')]. The example of multiple roles shows also a tricky corner-case, as the server may want to redact a contact in one role but same time not redact it due to other role attached to the same entity. Not sure if JSONPath allows to express this, but this might remain an implementation detail of the server and not particularly a concern of this draft (apart from the questions to 4.2 above). JG - Interesting tricky corner-case. I do believe it's an implementation detail, where the draft provides a redaction example based on the unredacted response that doesn't require the wildcard. --- Re previous discussion on multiple email addresses. Just a remark that after the last discussion on draft-ietf-regext-epp-eai it may be more common to have more than one email address. Likely RDAP needs to get EAI-aware as well on the response side. JG - Yes, agreed the provisioning side has a natural impact on RDAP side. jCard/vCard includes support for more than one "email" member (Cardinality of "*") take handle the use of an alternate email and includes support for UTF-8, so there is no need to extend RDAP to support EAI in EPP. Kind Regards, Pawel _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
