Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik <[e-mail]>]

Hi James,

See my feedback below.

Am 15.11.22 um 21:15 schrieb Gould, James:
> [...]
>
> 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.
[PK] Yes, the changed text is way better.
>
>      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.

[PK] Looking at the Abstract and the Introduction of the draft it reads 
"This document describes an RDAP extension for explicitly identifying 
redacted RDAP response fields, using JSONPath as the default expression 
language.". I see a clear focus on "identify", whereas such strong 
normative language actually influences the way the redaction is done. I 
don't think this should be the main focus of this draft and a bit softer 
SHOULD allows to align servers to the best practice without a dilemma if 
one can use the rdapConformance "redacted" even if placeholders are in 
use for whatever reason. Placeholders are perfectly fitting the 
"Redaction by Replacement Value Method", so also fitting the draft.

> [...]
>
> 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.

[PK] Fine

> [...]
> 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.

[PK] It would be of a great value to describe to which object the path 
refers to to make it clear for the implementers.
Maybe even worth considering to have 2 distinct members "originalPath" 
and "responsePath" where each one is clearly defined to be referring to 
a source or a result object respectively.

> 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?
[PK] Yes, I would support that.
>    
>
>
>      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.

[PK] The approach with a "template non-redacted RDAP response" may be 
interesting to take a deeper look into.
My first impression would be that such fits-all template may be 
difficult to build, accounting that an entity may have multiple roles 
assigned or that vCard allows also for custom fields the client would 
not be aware of.

Another approach would be to define a way of interpreting the JSONPath 
so that it is reversible or even defining a subset of JSONPath which is 
reversible in the narrower RDAP context.

In the end, implementing a client, I would rather want to rely on the 
"redacted name" from the "JSON Values Registry" for paths which have 
been deleted, and treating the path member as only informative.

If you agree for such processing by the client I suggest to put it down 
in the chapter 5 (maybe splitting it into server and client side).

> 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.

[PK] If WG feels we need to foresee support for more expression 
languages then the approach with JSON Values Registry is a good proposal.

>      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"?

[PK] Does it mean you intend to forbid fixed field positioning in all 
cases, meaning $.entities[0] would not be allowed?
In case of jCard I understand this is to prevent breaking the format, 
where the position plays a distinct role. What is the rationale to block 
it in all cases?

> [...]
>
> JG - Agreed that the registering a new JSON Values Registry Type and pre-registering the "jsonpath" expression language can help as stated above.

[PK] Fine

>      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.

[PK] I get that. This is just an observation, that "reverse search"  
will also define a JSON Value Registry" with a mapping of labels to 
JSONPaths. The risk is to end up with different labels for the same 
thing in context of redaction or reverse search.

It would be good to have some voices from the WG if we care about it.

>      ---
>
>      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.
[PK] I wanted to bring this up just in case (which obviously never 
happens) that the implementers of the server just copy-paste the examples...
> [...]

Kind Regards

Pawel