--
JG
*James Gould
*Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Date: *Saturday, December 10, 2022 at 3:31 AM
*To: *James Gould <jgo...@verisign.com>, "regext@ietf.org"
<regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] Request WGLC for
draft-ietf-regext-rdap-redacted
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
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
<http://secure-web.cisco.com/10wmXnAxec1RRrOtGTl4db_iLXMUtPfYFQrLzw-IA2PHbfNc9ze5KbXK3eWCAxJSio1lPtr_6pKioWeYvtLLrnVmZPkJWjQzok4esvmclUfrfkyRBCyDoJt_ryHsKxqZnXSbirKJywEyxB25w9OZqILiskden6igDu3eWZ8GZbgLoDDPJFLJVheJMYKuASxkT76O1U0JGRZ0wh5gYU7PxQ9YOsffUD0yMTCKG3C_S6kW9V15m-UfLxS6qupeP2j7qkhOOudeo--y4d2AzM-KUXiu-EqrQCbjBAN1DGuZ41tA/http%3A%2F%2Fverisigninc.com%2F>
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
*Date: *Tuesday, November 15, 2022 at 9:05 AM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, "regext@ietf.org"
<mailto:regext@ietf.org> <regext@ietf.org> <mailto:regext@ietf.org>
*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
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
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
regext@ietf.org
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: +39.0503153497
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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
<https://secure-web.cisco.com/1rA9AMtjPXivn2GGQB-ID4QUpd0YAumPZdCk9bomUeA-FW0jgWKt4BP-iZUjN9ZK5RHa3mQ0cgZR2CXGzCn7h5draw6tDsnn1tSB77lEpcrBTek47xmL8JcWRW7nrXcYWxlUJzXRAQbEPjV-zA4CToN9bL-qxyTxiM86Qdl2yf0VHGU9I7jvK8JrtFVS-STzmXEIFF8EaHSM31W6KF8L2VL4rQ4ZGnDL1tI2DNqDdq8GKQjafxSL34HzNHpWSllgqbY7K6JSCJ6773fZIRMhrDaF5f-HmjwipuKwciva27i0/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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
<http://secure-web.cisco.com/1Bl4tTWy6j96jLMQhvvpHAXNQ41oOlRskA5D53vZW-T6wL5phoY08mwHjoDtV7zFoXdlnARj7naYERSK3D1qW0xpd-s6AvJpc0cJ_SoIHX3iNlY-fO3_aB3ZnKwQ65nXXA7jCf0fUrGBdv98Qds0-Y14vwcKUTItJm97dg7egfABvUs7UEhDs1G_C1kNZM-5r7UzETiZxK5ob6tjf5_rSghdo7CrPwb334_rKFyPKsj7HGu2tNYK7iKhzdbMAJXxYdGfnJMRecJSzF646MoK8g1sAcpiQmU0lbVf_fwxvhLo/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
