Subject: Re: [regext] [Ext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

From: Gustavo Lozano <[email-masked]>
Date: Wed, 28 Jul 2021 18:53:28 +0000

Thank you Jim,

I provide my feedback prefixed with GL-.

I think that section 5 (JSONPath Considerations) of the I-D should also be generalized. 

I also suggest adding some text to guide RDAP extension authors about special JSONPath considerations. 

For example:

RDAP extensions MUST define any special JSONPath considerations required to identify redacted RDAP fields if the methods described in section 5 are insufficient.

Regards,
Gustavo

On 7/14/21, 10:51, "Gould, James" <[email-masked]> wrote:

    Gustavo,

    Thank you for your quick review and feedback.  I provide my replies to your feedback embedded below.

    -- 

    JG

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

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

    Verisign.com <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!o0GbJVtMeAviARQrIBEupbNyMpUHwB0iuziOJsE1Oo0VgCLnNySpyC1r1LAkgMxhPl8AgNQud4M$ >

    On 7/14/21, 11:50 AM, "regext on behalf of Gustavo Lozano" <[email-masked] on behalf of [email-masked]> wrote:

        Thank you, Jim and co-authors,

        This is needed, and hopefully this I-D could be published as an RFC sooner rather than later.

        I think that the text explaining the special treatment for jCard should be made generic. Currently, it appears that only jCard uses the position in the array to signal the type of information, but RDAP is extensible, and some extension may be doing or decide to use the same approach as jCard.

    JG - You are correct that there's an implied assumption that jCard will be the only RDAP case using fixed length arrays, and you're also correct that we can't foresee the forms of RDAP extensions that will be created.  I appreciate your suggested language that is more generic.  I made some language updates, but making it more generic is an improvement.  I'll look for similar jCard specific language in the draft.

        For example:

        Original:

        The Redaction by Removal Method can be done for all RDAP response fields other than the JSON arrays used with jCard [RFC7095]

        Suggestion:

        The Redaction by Removal Method can be done for all RDAP response fields other than response fields using the position in an array to signal the type of information (e.g., the JSON arrays used with jCard [RFC7095]).

    JG - My initial thought was to focus the language on the use of fixed length arrays, but I believe your approach of looking at the resulting redaction expression is better, which is to use a "position in an array".  I believe it's best to change "signal the type of information" to "signal the redacted field".  The end result is:

    The Redaction by Removal Method can be done for all RDAP response fields other than response fields using the position in an array to signal the redacted field (e.g., the JSON arrays used with jCard [RFC7095]).

GL- agree with the proposed text.

        Original:

        The Redaction by Removal Method MUST NOT be used to remove a field from a jCard [RFC7095] fixed array position, which will result in a non-conformant jCard [RFC7095] array definition.

        Suggestion:

        The Redaction by Removal Method MUST NOT be used to remove a field from a response field using the position in an array to signal the type of information (e.g., jCard [RFC7095] fixed array position, which removal of an individual data field will result in a non-conformant jCard [RFC7095] array definition).

    JG - I believe that the jCard reference could be broken out into a separate sentence as in:

    The Redaction by Removal Method MUST NOT be used to remove a field from a response field using the position in an 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.

GL- agree with the proposed text.

        Original:

        The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use jCard [RFC7095] arrays.

        Suggestion:

        The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the type of information (e.g., jCard [RFC7095] arrays).

    JG - Same change for "type of information" to "redacted field", as in:

    The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the redacted field (e.g., jCard [RFC7095] arrays).

GL- agree with the proposed text.

        Thank you,
        Gustavo

        On 7/12/21, 04:03, "regext on behalf of Gould, James" <[email-masked] on behalf of jgould=[email-masked]> wrote:

            The "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" draft-gould-regext-rdap-redacted has been published.  The goal of the draft is to describe an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.  Any review and feedback is welcome.

            Thanks,

            -- 

            JG

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

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

            Verisign.com <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksW5Dv4ypU$ >

            On 7/12/21, 6:47 AM, "[email-masked]" <[email-masked]> wrote:

                A new version of I-D, draft-gould-regext-rdap-redacted-00.txt
                has been successfully submitted by James Gould and posted to the
                IETF repository.

                Name:		draft-gould-regext-rdap-redacted
                Revision:	00
                Title:		Redacted Fields in the Registration Data Access Protocol (RDAP) Response
                Document date:	2021-07-12
                Group:		Individual Submission
                Pages:		24
                URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-gould-regext-rdap-redacted-00.txt__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksW4DeSFeo$ 
                Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gould-regext-rdap-redacted__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWx0K7Y6s$ 
                Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-gould-regext-rdap-redacted-00.html__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWVwNhHnw$ 
                Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-gould-regext-rdap-redacted__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWEbFQTh8$ 

                Abstract:
                   This document describes an RDAP extension for explicitly identifying
                   redacted RDAP response fields, using JSONPath as the default
                   expression language.

                The IETF Secretariat

            _______________________________________________
            regext mailing list
            [email-masked]
            https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWClMfK30$ 

        _______________________________________________
        regext mailing list
        [email-masked]
        https://urldefense.com/v3/__https://secure-web.cisco.com/1sbQYJ0RklzBQs5RMCovK0UQcaN9tI_4mvkBIWUefxhYjIgNOnEhmlBUSUNYz5fYas6OaXaJdT_mjVPi-GDDFNNO64WPfUB03Y1IEYZAU96OSZIKS5qjaXme4S5HWlJXtBoDHHCt9xMM1kHrGQhp2xW0QeHPHhdAskHxIlI8ZpIjEeZ6uSqPUZVDGQOoCHzzu9rinzE5L6iXprR_pTJikt_DhEFxDP6uS5ZtUB1WlhpHujpVTrKs6OKQdjgT4-o4PL1CF-GSxrqJDJ_GdwnbEGg/https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fregext__;JSUlJSUl!!PtGJab4!o0GbJVtMeAviARQrIBEupbNyMpUHwB0iuziOJsE1Oo0VgCLnNySpyC1r1LAkgMxhPl8A4sqIB4E$

---

From: "Gould, James" <[email-masked]>
Date: Wed, 28 Jul 2021 19:06:34 +0000

Gustavo, 

Thanks for the additional feedback.  The updates based on your prior feedback will be in the next version of the draft.  I like your suggested text for the JSONPath Considerations.  I look forward to the discussion on the draft at the REGEXT meeting today.

-- 
 
JG

James Gould
Fellow Engineer

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

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

On 7/28/21, 2:53 PM, "Gustavo Lozano" <[email-masked]> wrote:

    Thank you Jim,

    For example:

    Regards,
    Gustavo

        Gustavo,

        -- 

        JG

        James Gould
        Fellow Engineer

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

            For example:

            Original:

            Suggestion:

            Original:

            Suggestion:

            Original:

            Suggestion:

            Thank you,
            Gustavo

                Thanks,

                -- 

                JG

                James Gould
                Fellow Engineer

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

                    Abstract:

                    The IETF Secretariat