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

From: Gustavo Lozano <[email-masked]>
Date: Wed, 14 Jul 2021 15:49:48 +0000

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.

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

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

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

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$

---

From: "Gould, James" <[email-masked]>
Date: Wed, 14 Jul 2021 17:50:52 +0000

Gustavo,

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

-- 
 
JG

James Gould
Fellow Engineer

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

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

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

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:

    Suggestion:

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

    Original:

    Suggestion:

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.

    Original:

    Suggestion:

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

    Thank you,
    Gustavo

        Thanks,

        -- 

        JG

        James Gould
        Fellow Engineer

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

            Abstract:

            The IETF Secretariat

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1sbQYJ0RklzBQs5RMCovK0UQcaN9tI_4mvkBIWUefxhYjIgNOnEhmlBUSUNYz5fYas6OaXaJdT_mjVPi-GDDFNNO64WPfUB03Y1IEYZAU96OSZIKS5qjaXme4S5HWlJXtBoDHHCt9xMM1kHrGQhp2xW0QeHPHhdAskHxIlI8ZpIjEeZ6uSqPUZVDGQOoCHzzu9rinzE5L6iXprR_pTJikt_DhEFxDP6uS5ZtUB1WlhpHujpVTrKs6OKQdjgT4-o4PL1CF-GSxrqJDJ_GdwnbEGg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 16 Jul 2021 10:56:22 +0000

Mario,

I provide responses embedded below with a JG2 prefix.

--

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<http://verisigninc.com/>

From: Mario Loffredo <[email-masked]>
Date: Friday, July 16, 2021 at 3:56 AM
To: James Gould <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

Hi James,

please find my replies below.
Il 15/07/2021 19:40, Gould, James ha scritto:
Mario,

My responses are 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<http://secure-web.cisco.com/11V8HZGNXCwVH0Y4yV8VW9bm0e2IM1d3xYq7E4pvU3UfBDV58X77rXsyRZ5JFKrA1h8frY7uqsM5w89qNqBurK5D8MvVPE_pTo0iU4-g5xzkuWaCxDxtdSTwfy-X5V24fuk0PH_KzlO4-6aaEQ48IYhEy66JWrn2teYjUJEjZ7eLa7UNVb-atyVyyRc3PkW4fKFTFc5LjrZ_donH57MCm9prsuKtA5T5IjvCcQYkB4qdbFn-YTuBiIwbakh3jlEsZfBoVLQFntkZpPMOMVEEbVA/http%3A%2F%2Fverisigninc.com%2F>

From: Mario Loffredo <[email-masked]><mailto:[email-masked]>
Date: Thursday, July 15, 2021 at 5:31 AM
To: James Gould <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Fwd: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

Hi James,

please find my comments below prefixed by [ML].

-------- Messaggio Inoltrato --------
Oggetto:

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

Data:

Wed, 14 Jul 2021 14:06:47 +0000

Mittente:

Gould, James <jgould=[email-masked]><mailto:jgould=[email-masked]>

A:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Mario,

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

--

 JG

James Gould

Fellow Engineer

[email-masked]<mailto:[email-masked]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1AwKlvS6mjX9gmbKA1esca1gF6gxkHG4Hoq0dLgqeXboqam0LCBCpr8v4YeIi-PL4RHebdkRdmVtjkdl7oEzPIEggNkSHF2MjHGUBV30M8XyMTqLJBjKRIU5jN3-fYZRQliPDXzrDOAhkH4i0BW_HjO9j1PRk_MfBQWzDucjLLtB3U_2AeOEIEBGBQzU6x-Z_zCDwlsvcPJ6eCukHyjxYhuMecKPAfiDTlb04zEM-Zkj10uizRdyIj69BBkvs3XUz/http%3A%2F%2Fverisigninc.com%2F>

On 7/14/21, 3:58 AM, "Mario Loffredo" <[email-masked]><mailto:[email-masked]> wrote:

    Hi all,

    Il 12/07/2021 13:26, Gould, James ha scritto:

    > Marc,

    > Thank you for the quick review and feedback.  Below are responses to your early comments:

    >      - would be good to include specific text about jscontact, so when we switch to it, this document does not need rev.

    > Agreed, that was thought about while drafting, but we initially left it out.  I'm confident that the extension will work with JSContact, but some text would help for clarity.

    I guess it will work even better than with jCard! JSContact is more     object-oriented than jCard and the json path expressions are simpler     since maps are mostly used to represent collections (e.g.

    "$.entities[?(@.roles[0]=='registrant')].jscard.phones.voice.phone"<mailto:$.entities[?(@.roles[0]=='registrant')].jscard.phones.voice.phone>     instead of     "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[1].type=='voice')]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[1].type=='voice')]>)

JG - Yes, JSContact is much easier to express via JSONPath, since there is no dependency on the use of JSON arrays.

    Here in the following a first feedback from my side about the document:

    - if, as it seems, the "name" property is unique in the "redacted"     array, I would prefer to define "redacted" as a map where the "name"     value is the map key. In theory, every RDAP information can be redacted     but, in practice, the number of RDAP properties usually redacted is     limited. If the possible "name" values were standardized, il would be     easier for RDAP clients implementers to check and pick a property inside     the collection of redacted properties.

JG - Agreed, it would be ideal for the "name" property to unique and easy to key off of by the client.  The JSONPath expression provides the technical reference, while the "name" property can represent the logical reference.  We didn't want to go down the IANA registry route in draft-gould-regext-rdap-redacted, but if we add a RDAP JSON Values type for the redaction reason, we could also add an RDAP JSON Values type of the redaction name.  The question would be whether all "name" property values would need to be registered in the RDAP JSON Values registry.  If that is not the case, then we would need change the "name" member to be a JSON object with the "description" and "type" members used for registered and unregistered values in RFC 9083.

    - another possible pre-defined value for "pathLang" might be     "jsonpointer" as an alternative syntax to indentify a value within a     JSON doc.

JG - I don't believe JSON Pointer will work for RDAP based on the need for the conditional expressions (e.g., "$.entities[?(@.roles[0]=='registrant')]"<mailto:$.entities[?(@.roles[0]=='registrant')]>).  Do you see a way that JSON Pointer could be used for RDAP?  I would only add it if it will work for RDAP.

[ML] - I think it depends on whether the "jsonpath" is meant as a way to identify a generic RDAP response field or a specific field in the current RDAP response. Surely, unlike JSONPointer, JSONPath allows to select a field nested in an array regardless of the position. Therefore, it is able to represent multiple cases through the same respresentations. However, an RDAP profile might use conventions (e.g. the registrant is always the first entity in the array of entities associated to a domain) making the use of JSONPath filters redundant. In additon, there are cases where JSONPointer can be used straightforwardly: for example, a entity lookup response using JSContact :-) . Anyway, I agree with you that JSONPath fits better than JSONPointer.
JG – Our initial intention was to use JSONPointer, but it was clear early on that it would not meet the needs for RDAP responses.  My recommendation is to stick with JSONPath and if someone sees and can show that JSONPointer is a viable expression language for RDAP redaction, then we can make it a pre-defined option.
[ML] - Agreed.

- it seems to me that the document assumes that the role used to     identify the redacted entity within the array of entities should be in     the first position of "roles" array. Maybe such assumption should be     added somewhere in the document.

JG - That is the convention, but if there are multiple roles, the server could choose to use a different role value reference.  There is the option for a contact to serve multiple roles ("registrant", " administrative", "technical", "billing"), but it's unclear whether that is actually used.  If the multi-role contact is redacted by role, then it will add complexity from a redaction perspective, but it can be done.  In the end, I believe this will come down to a implementation consideration item.

[ML] - Generally, an entity is redacted without regard to the role but based on other conditions: whether the entity represents an individual or not, whether the entity have expressed the explicit consent for publishing or not. At least for ccTLDs, it is normal that an entity is both the registrant and the amministrative contact linked to a domain.

JG – Redaction based on whether the contact is an individual or provides consent does make sense, but the ICANN draft policy differentiates the redacted fields based on role.  For ccTLDs if a contact is both the registrant and administrative contact for a domain, does the RDAP response include a single entity with two roles instead of including two entities each with a single role?  If redaction is dependent on role, it would be simpler for the server and the client to return two entities each with a single role and with a different set of redacted fields.

[ML] - I can speak on behalf of .it. Our RDAP server returns only one entity with two roles. After all, the protocol has been designed to consider that and it seems to me an efficient soultion. In my opinion, it would be more logical and correct that, if the redacted properties were based on roles and an entity has more roles, the redacted properties of the entity should be the union of the redacted properties per each role. Otherwise, there might be a risk to result in a privacy violation.

Please correct me if I misunderstood the content of section 2.7.4 of RDAP response profile for gTLDs and I'm giving a wrong example:

if the Organization information MUST be omitted for administrative but not for registrant entities, if an entity is both registrant and administrative, the Organization information MUST not be returned anyway.

At least when the same database object is used for different roles, it's easy to implement that.

JG2 – Thanks, that is good to know and does make sense.  The assumption in the draft is the use of role-based redaction, but I believe that the multiple role approach will work as well.  We’ll consider the multiple role approach as well to ensure that both are effectively handled.  Let us know if you see any issues.

 - there is a typo in the json path expression of  "Registrant Street"

JG - What typo do you see in the JSON Path expression of "Registrant Street".  I tested the "Registrant Street" JSONPath expression "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='adr')][3][:3]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='adr')][3][:3]> against the unredacted RDAP response, with the result being:

[

  "",

  "Suite 1235",

  "4321 Rue Somewhere"

]

[ML] - Understood. You considered both extended address and post office box as street components. I have always considered the street information made up only by the third ADR component beacuse RFC6350 recommends not to use the first two components to increase interoperability (see below). That being said, I admit that your JSONPath is able to cover any street representation.

       Unlike the use in RFC8977, a JSONPath expression is allowed to select an array of values in order to communicate that all the values are redacted.

       "Experience with vCard 3 has shown that the first two components

      (post office box and extended address) are plagued with many

      interoperability issues.  To ensure maximal interoperability,

      their values SHOULD be empty." (RFC6350 section 6.3.1)

JG – I was unsure whether the street would logically match just the third ADR component of the ADR-value or the first three ADR components.  In the end, I viewed the first three ADR components as being related to the street address (post office box, the extended address – apartment or suite number, street address), but if the street address is only the third ADR component, the example in the draft can be updated.  RFC 9083 does include a reference to the second ADR component with “Suite 1234”, which is what was also used in draft-gould-regext-rdap-redacted.  If the intent was to redact the street address, should “Suite 1234” not be also redacted even if RFC 6350 recommends for it to be empty?
 [ML] For sure, it should. As I wrote in my previous reply, it is better to consider also unrecommended cases so the JSONPath selecting the first three ADR components as street information is preferrable.

JG2 – Great, we’ll keep the street redaction example covering the first three ADR components.

[ML] - Another feedback about implementing this extension in search responses. Provided that this is not the .it case where searches are allowed only to users legitimated to see the full contact information, I wonder how RDAP servers permiiting searches more or less publicly might implement it.

       Returning the list of all the redacted JSON values included in the response seems to me inefficient. On the other hand, relying on the JSONPath capability to select a result set, it would be wrong to use a single generic JSONPath expression

      (e.g. use "$.domainSearchResults[*].entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]"<mailto:$.domainSearchResults[*].entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]> to communicate that the emails of all domains' registrants are redacted) because, in general, the same property in different results could be either redacted or unredacted.

       Do you think the document should address this topic and how?

JG – The extension is targeted for lookups over searches, since searches would be too complex.  We can add something to the draft to specify that the extension applies to RDAP lookup responses and not search responses.  Does that make sense to you?
[ML] - Yes, it does.

JG2 – The draft will be updated for this.

    Best,

    Mario

>
> - I really would like to have an IANA registry for the « reason » property. Because this would be potentially displayed to the user, and to avoid having all variations of the same reason in different words. A registry of reserved words would also facilitate translation in multiple languages.
>
> We had a desire to stay away from needing to setup an IANA registry for redaction. I view the reason property as not a good candidate for an IANA registry, since it's meant to be a human readable informational value that includes normative language not to be used as a client processing dependency. This is a good discussion item.
>
> Thanks,
>
-- Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://secure-web.cisco.com/1F-PFooJyrWLg51lyW_I49Zvwy3moYXof6OwGqaZON9_0DcwS-s4HC3KttHlW4-GTU-3j7eTkRexCFzAuK9qR5TFk1Va8rwSoh15OdINxFIShnToELNciLpmFWsMNghBtzhTGEfz81tSFv-8jpnVkIF56EAcX0m47l_U0xLdYxjWxvkBykLE6XGyZkw-IHz_8LfdHOV6Ja-dDltW2jsD7CdSMhuy3B4g2ihEL5ekGFFizXUM5jM8rQrdTICQAhGxBqTHe6CwiveYGEUunTsQJxA/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1KSounj1EI0mAuJ5HeObfyLj0PmjQaZ4MvzHpbjQfIsuIUCHOG5lUy9Wi1aoZ2pV114_EkwQv8n5wAGpR5rCOc-aLnkCzWfKDA7jmK1dQuhJIR2PclRd1U7I1LmlUUveLwM9A37iFrBM79cRZfv427hTQRpUNnVB2ZC_DQbFy48OKWRBcJixbykLLbL0AYqxHLzVw36kDRsfVwe-fy80BWMiqXYYjd12-yze4FgAGumlG6YGATEuEFqK7eFyytXPV/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

regext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1v3VpW3nP3bJHUEecbk43YkaiYaUg17A_BLVyy_pbCzbPbOUayVl5DQyeXMu_rK2UF1ygz66cmPq6TzkGALoFP1W1vFQUNhRXzgTI2BGdIUPTFLlWs2yyLezPNDKpsWNNuzarfxUsLVZZ1yrBd6lzm0ZT1h2MpPIOUuazVO-uzjCoLHXEfQme8NWoySoUKewSzPSD4XBZG4s2ftljTCN-8RDCatJU0VPNAGMQRq_LGpICWnQmgvTuFbemq3PFxOXV3IuIJZDm9ZRTPzxJHQnEGw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--

Dr. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: +39.0503153497

Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1er9Ghy6yNoDflZC7OBzrPTNYfSJY3ctni1dtwVLT54-b0ymXYyVfCWbeYx_HfuzCw_t_WFYfjtdhwU3Kgc2Z3vrhVr8_AcfD2f_XIXMnCH6VQUwLBhQfz5C3vAt1480iB2kjVXuZEoabuii3cxi2T_T0zGA4qlXFONYeZ6zpDNXdGIly9hXHLNkLcgt5JBTpq2aae4QNOXs69ECUT3VA7Gf304VGqJSWfzfBAiO0hdwDnbVl76p1Z4wRPwMIiSdI-bNuk955eOeqE8pLHb7mvw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>