Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted

[Mario Loffredo <[e-mail]>]

Hi James,

please find my comments below.

Il 09/12/2022 19:15, Gould, James ha scritto:
>
> Mario,
>
> Sorry for the delay in responding to your feedback.  Thanks for the 
> feedback and below are the responses to it.
>
> -- 
>
> 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/>
>
> *From: *Mario Loffredo <[e-mail]>
> *Date: *Tuesday, November 15, 2022 at 9:05 AM
> *To: *James Gould <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Request WGLC for 
> draft-ietf-regext-rdap-redacted
>
> Hi James,
>
> some comments from my side:
>
> 1) With reference to the following sentence in section 3.2:
>
> such as "" for a jCard [RFC7095] Text ("text") property or null for non-Text ("text") properties.
>
> it seems to me that RFC7095 doesn't include a clear statement in that 
> sense.
>
> Some VCard types (i.e. text, uri, language-tag, utc-offset, and all 
> date type variants) are mapped to JSON strings, other VCard types are 
> mapped to other JSON primitive types (i.e number, boolean).
>
> Given that, apart from "fn"  that is a required "text" property, a 
> JSON string can be either null or empty.
>
> For sure, the use of the empty string makes more sense for "text" 
> values, but null value is not clearly prohibited for the other VCard 
> properties mapped to JSON strings.
>
> JG – Yes, the other jCard properties may be mapped to a JSON string, 
> but they include additional string format requirements that would not 
> be met with the use of an empty string.  The reference to the Text 
> (“text”) property does not apply to the other jCard properties that 
> map to a JSON string, so the redaction is handled with the use of a 
> null value.
>
> 2) WIth regard to redaction by replacement method, should the example 
> in Fig.7 be updated as in the following:
>
> OLD
>
>     "redacted": [
>       {
>         "name": {
>           "type": "Registrant Email"
>         },
>         "path":"$.entities[?(@.roles[0]=='registrant')].  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]>
>                   vcardArray[1][?(@[0]=='email')][3]"  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]>,
>         "replacementPath":"$.entities[?(@.roles[0]=='registrant')].  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]>
>                   vcardArray[1][?(@[0]=='contact-uri')][3]"  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]>,
>         "pathLang": "jsonpath",
>         "method": "replacementValue",
>       }
>     ]
>
> NEW
>
>     "redacted": [
>       {
>         "name": {
>           "type": "Registrant Email"
>         },
>         "path":"$.entities[?(@.roles[0]=='registrant')].  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]>
>                   vcardArray[1][?(@[0]=='email')]"  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]>,
>         "replacementPath":"$.entities[?(@.roles[0]=='registrant')].  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]>
>                   vcardArray[1][?(@[0]=='contact-uri')]"  <mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]>,
>         "pathLang": "jsonpath",
>         "method": "replacementValue",
>       }
>     ]
>
> Based on the example in Fig.6, the "email" property instead of the 
> "email" value is replaced.
>
> JG – Yes, I agree that the “email” property instead of the “email” 
> value is replaced.  This will be addressed in 
> draft-ietf-regext-rdap-redacted-10.
>
> 3) Would rephrase the following sentence in section 4.2
>
> OLD
>
> The "redacted" member contains an array of redacted
>     objects with the following child members
>
> NEW
>
> The "redacted" member contains an array of
>     objects with the following child members
>
> The objects in the "redacted" array are not redacted but rather the 
> response fields represented by those objects.
>
> JG – This will be updated in draft-ietf-regext-rdap-redacted-10.
>
> 4) Wonder if section 6.2 should include an entry for pathLang.
>
> JG – Yes, based on the feedback from Pawel Kowalik, the “redacted 
> expression language” type will be added with an initial registration 
> of the “jsonpath” value for the JSON Values Registry.
>
> 5) A last feedback about JSONPath Considerations:
>
> 5.a) Is it allowed to use wildcard in JSONPath? Think it could be 
> useful especially when the same redaction rule is applied to each 
> result of a search response.
>
> For example, if a registry policy consists in redacting all the domain 
> handles, the "redacted" content could simply be:
>
>             "redacted": [
>               {
>                 "name": {
>                   "type": "Registry Domain ID"
>                 },
>                 "path": "$.domainSearchResults[*].handle",
>                 "pathLang": "jsonpath",
>                 "method": "removal",
>                 "reason": {
>                   "type": "Server policy"
>                 }
>               }
>             ]
>
> JG – Actually for searches the “redacted” member can be included on a 
> per-object basis, since the redaction may be different per object.  
> Attempting to define crosscutting redaction definitions for all 
> objects included in the search seems like something the server could 
> do, but I don’t believe it should be encouraged.
>
> 5.b) I consider this a corner case so feel free to ignore it  ;-)
>
> The VCard label property (as well as the JSContact fullAddress 
> property) is usually derived from the postal address information.
>
> When the postal address is partially redacted, what should be the 
> label value and the related redaction method?
>
> If you think it's worth managing this case, I would suggest a 
> conservative solution:  the label property should be omitted and the 
> redaction method should be "removal".
>
> JG – The rule is if the property can be and is removed due to 
> redaction, then it is omitted, and the redaction method should be 
> “removal”.  I’m not sure if this fully answers your feedback, so 
> please let me know with an example if it doesn’t.
>
[ML]  As I wrote in my previous mail, maybe it's not worth addressing 
this case. In general, it is connected with the redaction of vCard 
elements, namely the FN property and the LABEL parameter of the ADR 
property, that are generated by formatting their structured 
counterparts. If the structured components get partially redacted by the 
emptyValue redaction method, what redaction method should I use to 
redact the formatted versions?

Here in the following an example clarifying my question.

Before redaction:

		[
                    "adr",
                    {"label": "Suite 1236\n4321 Rue Somewhere\nQuebec\QC\G1V 2M2\Canada"},
                    "text",
                    [
                      "",
                      "Suite 1236",
                      "4321 Rue Somewhere",
                      "Quebec",
                      "QC",
                      "G1V 2M2",
                      "Canada"
                    ]
                  ]

After redaction:

1)
		[
                    "adr",
                    {"label": "QC\nCanada"},
                    "text",
                    [
                      "",
                      "",
                      "",
                      "",
                      "QC",
                      "",
                      "Canada"
                    ]
                  ]
2)

		[
                    "adr",
                    {},
                    "text",
                    [
                      "",
                      "",
                      "",
                      "",
                      "QC",
                      "",
                      "Canada"
                    ]
                  ]

Since the specification doesn't allow the server to signal that a value 
has been partially redacted, and I don't see the need to add another 
redaction method only for this corner case, my proposal was simply the 
following: "those properties that are generated from other properties 
that can be partially redacted must be redacted by using the removal 
method" (Solution 2)

Best,

Mario


> Hope it could be helpful.
>
> Best,
>
> Mario
>
> Il 10/11/2022 19:38, Gould, James ha scritto:
>
>     This is a formal request to start the WGLC for
>     draft-ietf-regext-rdap-redacted.  There is a normative reference
>     to draft-ietf-jsonpath-base, which has a JSONPath working group
>     November milestone. draft-ietf-jsonpath-base looks stable and can
>     progress in parallel with draft-ietf-regext-rdap-redacted.
>
>     Thanks,
>
>     -- 
>
>     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://secure-web.cisco.com/1jBgmRGLp97BwyI56ZY6E2KnhXLBn_CyaRjxVZ7GqU5nP4VoGbDmOFaSadTLrZ8OaIMWwNr4CLXsVIYNhnH4Z3c6przEWV0581stOfOtCDYyVb1U8iX-OaeglUaY6UIjRbRsoaAcqnx12w7uDgnjrwnhLrtSCH3NQK20VhpKXQbAofvo4jOJsx4cHjD5sxmv-xKgfyjXZgr7oOpxU9z41XgH02hJZZTYbogCf05948JANuWS0T4DojwwmNtmQHoN9UjVqPRqZKAn7gbjnO0xXK3ZDaxx9N9iz65hy3ZqIgQYHxdSLk5KUHbNvQydrwCxd/http%3A%2F%2Fverisigninc.com%2F>
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext  <https://secure-web.cisco.com/1QZXPKZg0yOi5FGPtQR9fKFNSa-mIVnC7WC4ALwt1eRfK3-ypZSt6_2xY-hSaVmgzAytTYYHcnL4rCXxWO2UpEtkMlh-OegPiK5nrIShRzg2hBlREYZPS41o1IwIWcM7UZPGQ-FxQBxkkf8fRsG27ZJPh6SN4Npz5Nx0eTyp0BNyD27_AEHQOQGphegY8qsrmx-Wjd9q7Csh129rmKkvKVxpZzed_u_8Pwyn4g4DN11Ns2RGRyh6-ymPx7BK5CxqUGI6OovchjtlylImbPICIi7KiCZMvnjcPCyn_ZDbQbxVQpIu6ikjianxcAM8RpdtD/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
> -- 
> Dott. 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: [phone]
> Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/139AqdF7WT3CdxSSc0UPSoDgA0gl9_QwVKklekryCslll0JvKfIWV4X16QAKacmsRBjPmY6-F04c28s5zpz2HwT6ki7ON7XQHsnRXipvn3m1NoGxfR9XMNRGTtoSlaoXahD0z-bP-mSUPsraAy5ewotwaYuTsKuafF8T5HN8JqEL4pqYsq1WAdl8WS_bHigbb8mVKIhqTDuRazKzVCpoByy52N_M-Hf8megqz4jAbIU_D7CgzVTQH7GQXldLgfms9L0ugpZtQ0bewrH_9DBeNO0aiY2BRkZ8adIM_8V-TsGl3qCbgdfLzBl6RNTz79GpF/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dott. 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo