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

["Gould, James" <[e-mail]>]

Pawel,

My responses are embedded with “JG3 –“.

Thanks,


--

JG

[cid:image001.png@01D8FF14.0C23C810]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Pawel Kowalik <[e-mail]>
Date: Wednesday, November 23, 2022 at 5:58 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09


Hi James,

My comments also inline.
Am 22.11.22 um 14:18 schrieb Gould, James:

[...]



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



JG2 - The use of placeholder text, such as "REDACTED", is an alternative approach that is incompatible with the method of redaction defined in this draft.  The draft explicitly states that the use of placeholder text MUST NOT be used for redaction, and it has no impact on the use of placeholder text for other purposes.

[PK2] This is exactly what I allude to. The document describes not only the "extension for explicitly identifying redacted RDAP response fields" but also dictates what methods of redaction are allowed and which not. If there is consensus that the document also shall mandate the methods of redaction I think the Abstract and Introduction part should state it as well.

The real question is whether the goal of making clear what part of the dataset was redacted not enough for this draft.
For the client the indication that some data is not real, don't use it, is just enough of information, no matter if the data was removed, set to null, empty or otherwise replaced, isn't it?

JG3 – What triggered the creation of this extension was a proposal to use placeholder text for redaction, which in my opinion is an anti-pattern that needs to be directly addressed.  I believe that you see the need to support a transition period that would be up to server policy.  See my comment below related to creating a Transition Considerations section to make this explicit.  The draft can define the methods for redaction, disallow the use of placeholder text for redaction outside of a transition period, and add explicit support for a transition period with a set of considerations.  Does this meet your needs?

Populating the existing value with a static placeholder value as a signal for redaction is different from what is defined for the "Redaction by Replacement Value Method", which changes the value to a non-static value or moves the location of the value.
[PK2] I believe it should be perfectly valid to replace one email with another email (for example privacy proxy email) without moving it, shouldn't it? For me it would be "Redaction by Replacement Value Method" where both paths are same.

JG3 – Yes, use of a privacy proxy email is a form of "Redaction by Replacement Value Method", since the real value is not being provided but a replacement value is being used instead.  In this case the “method” value is “replacementValue” and the “replacementPath” is not used.  Does this need to be clarified in the draft, since the intent is to support replacing the value in place or replacing the value using an alternate field, such as the replacement with the “contact—uri” property?


  If I currently implemented placeholder text for the purpose of redaction and I decided to implement redaction using the approach defined in this draft, then I don't see the purpose of running them in parallel even during a transition period, since clients should be notified of the transition and the draft includes the needed signaling using the "redacted" rdapConformance value.  Is there a specific use case that would warrant a softer transition?  If there is a softer transition use case warranted, then adding a Transition Considerations section, such as defined in section 6 of RFC 9154 "EPP Secure Authorization Information for Transfer, may be needed.

[PK2] Assuming the initial situation: RDAP server does not support "redacted" extension and puts the placeholder values and all the clients do not support "redacted" extension but know how to interpret the placeholder.

Now if the server would just turn on "redacted" first, not waiting for the clients, being fully compatible with the extension it would have to change the redaction with either empty value or removal of the fields. By doing this the clients which are not aware of "redacted" extension would potentially break due to changed behavior.

To avoid it the server would have to first make sure all clients support "redacted" before switching. This is somewhat impossible, as client is not informing the server in any way which extension it supports. If it would have a way to inform the server the problem would be gone as well, as server might have offered different representation to different clients. The other way around is to relax the requirement and allow the server operators to manage this.

SHOULD instead of MUST would give the operators a bit more of flexibility and same time none of the benefits of this draft would be lost.

JG3 – Ok, that helps.  I believe the biggest issue from a client perspective is when they expect a non-empty value, and the server implements the Redaction by Empty Value Method and then returns an empty value.  The use of the placeholder redaction text can be used in parallel with draft-ietf-regext-rdap-redacted during a transition period.  The duration of the transition period would be up to server policy.  What I don’t want to introduce is parallel forms of redaction for beyond a transition period.  How about including the definition of a transition period in a Transition Considerations section and updating the MUST NOT language to “The use of placeholder text … MUST NOT be used for redaction outside of a transition period defined in Section X . In the Transition Considerations section, it can define that placeholder redaction text may exist and may overlap with this extension during a transition period that is up to server policy.  Then there can be a set of considerations for the server and client in making the transition.  I believe this would address the transition more explicitly and leave the timing of the transition up to server policy.  Do you agree?

[...]

    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.



JG2 - I'm not sure what is meant by JSONPath that is reversable.  I believe that JSONPath needs to be used as defined.
[PK2] Reversable means that you can unambiguously re-create the original object structure based on the path. Normalized JSONPath have this property (see 2.8 of JSONPath draft) but may not be the best in case of array members identified by a property value of array member, like in jCard. The expressions like $.entities[?(@.roles[0]=='registrant')] can be also reversible, but this is not true for just any JSONPath expression. If we would define a narrowed down definition of JSONPath expressions which are allowed, we could achieve the property of reversibility and maybe even that one kind of object or property would have exactly one and only possible JSONPath describing it. Again - it's just an idea how to deal with removed paths. It may be also not worth following if we assume "redacted name" would be the leading property (see below).

JG3 – Thanks for the reference, I’ll review it and see whether something can be used.  My initial thought is that it’s going to be too complex and won’t cover the broad set of use cases in RDAP.  Right now, we’ll assume that it can’t be used in draft-ietf-regext-rdap-redacted, but it’s being reviewed.



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



JG2 - From a client perspective, I believe I would first key off the "redacted name" to route my display logic and then I would utilize a template RDAP response overlaid with the actual response and the JSONPath to indicate the redacted values.  It would be nice to hear from some clients on this to identify useful client JSONPath considerations.
[PK2] If I would be implementing the client likely I will do exactly this.

JG3 – Ok, the “JSONPath Considerations” section will have two subsections of “JSONPath Client Considerations” and “JSONPath Server Considerations”, where the above will be the starting JSONPath client consideration.  How about the JSONPath Client Consideration:

When the server is using the Redaction By Removal Method<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal> (Section 3.1<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal>) or the Redaction by Replacement Value Method<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value> (Section 3.3<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value>) with an alternate field value, the JSONPath expression of the "path" member will not resolve successfully with the redacted response. The client can first key off the "name" member for display logic and utilize a template RDAP response overlaid with the redacted response to successfully resolve the JSONPath expression.



[...]



JG2 - Your reference to $.entities[0] is an example of an element in an array, but its' not referring to a fixed field position of a fixed length array, such as the case for redacting the "fn" jCard property.  There is no intent to block all cases of redacting objects via the use of an array position.  Is there better language than "using the fixed field position of a fixed length array" to provide the proper scope?

OK, now I get it. My proposal would be: "The Redaction by Removal Method MUST NOT be used to remove an element of an array where position of the elements in the array determines semantic meaning of the element."

JG3 – Just a tweak, how about “The Redaction by Removal Method MUST NOT be used to remove an element of an array where the position of the element in the array determines semantic meaning.”?



Kind Regards,

Pawel