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

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

Pawel,

Thank you for the detailed review.  I provide responses to your feedback embedded below.

-- 
 
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/14/22, 12:18 PM, "Pawel Kowalik" <[e-mail]> 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