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

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

Pawel,

Thanks again for your feedback.  You'll find my responses to your feedback embedded below with "JG2 -".  

-- 
 
JG



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

On 11/16/22, 12:14 PM, "Pawel Kowalik" <[e-mail]> wrote:

    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.

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

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

JG2 - I believe the object (before or after redaction) can be covered in the description of the redaction methods (Reaction by Removal Method applies to the object before redaction, Redaction by Empty Value Method applies to both the object before and after the redaction, and Redaction by Replacement Value applies to after redaction).  The redaction "method" member provides the needed signal.  The clarification will be added for each of the redaction methods in the next version of the draft.     

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

JG2 - I agree that a fits-all template may be difficult to build, where the template would need to be incrementally updated based on new response patterns.  There may be the need for a template per server or a template per server operator since the approach taken by various servers and server operators may vary too much.  I believe an entity having multiple roles is a corner case and the server can mitigate the corner case by returning copies of the entity each with a single role.  De-normalizing the data makes for larger responses but would simplify things for the clients.  

    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.

    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.  

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

JG2 - Yes, the WG feedback did include support for more expression languages.  The JSON Values Registry "redacted expression language" Type with a pre-registration of the Value "jsonpath" will be included in the next version of the draft.

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

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?

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

JG2 - I believe the Value entries must be unique per Type.  I don’t see value in attempting to make all Value entries unique across the Types.  Adding the new Type values will support the extensibility needed for redaction with the needed isolation.  

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