Jasdip,
Agreed. If providing clarity around transitioning to the old way to
the new way makes sense to keep the MUST NOT language, then that can
certainly be done. The transition considerations section could
include an overlap period that supports a soft cutover. A similar
kind of section can be found for the Secure Authorization Information
for Transfer RFC 9154
(https://datatracker.ietf.org/doc/html/rfc9154#section-6); although
the redaction transition section would be much simpler. With that
I’ll add back in inclusion of the MUST NOT language and the transition
considerations section to the list of options, as option 5.
1.Keep MUST NOT – The Section 3 sentence is “The use of placeholder
text for the values of the RDAP fields, such as the placeholder text
"XXXX", MUST NOT be used for redaction.”.
2.Change MUST NOT to SHOULD NOT – This enables the draft to recommend
that placeholder text not be used for redaction, but still enable the
server to support it in parallel with the redaction methods defined in
the extension. The Section 3 sentence would become “The use of
placeholder text for the values of the RDAP fields, such as the
placeholder text "XXXX", SHOULD NOT be used for redaction.”.
3.Remove the normative language – Change the Section 3 sentence to
“The use of placeholder text for the values of the RDAP fields, such
as the placeholder text "XXXX", has been used for redaction.”.
4.Remove reference to placeholder text use for redaction – Just lead
Section 3 with the sentence “This section covers the redaction methods
that can be used with the redaction signaling defined in Section 4.2
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-redacted%23section-4.2&data=05%7C01%7Cjkolker%40godaddy.com%7C03bdff32aeb64d19ef4308daceb9b1ca%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C638049594251190871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V%2BP67JW8FHgh2fmp3u3peTK27KTc%2BMeOMQ6zIQcI8j8%3D&reserved=0>.”.
5.Keep MUST NOT with Transition Considerations section – Same as
option 1, but with the addition of a Transition Considerations section
that provides guidance on transition of the use of placeholder text
redaction to the use of the redaction extension.
My preference order would be Option 1, Option 5, and then Option 3 as
a fallback.
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://verisigninc.com/>
*From: *Jasdip Singh <jasd...@arin.net>
*Date: *Friday, December 9, 2022 at 9:02 AM
*To: *"Gould, James" <jgould=40verisign....@dmarc.ietf.org>, Jody
Kolker <jkol...@godaddy.com>, "kowa...@denic.de" <kowa...@denic.de>,
"draft-ietf-regext-rdap-redac...@ietf.org"
<draft-ietf-regext-rdap-redac...@ietf.org>
*Cc: *"regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] Review of
draft-ietf-regext-rdap-redacted-09
*Resent-From: *<alias-boun...@ietf.org>
*Resent-To: *David Smith <dsm...@verisign.com>, Roger Carney
<rcar...@godaddy.com>, James Gould <jgo...@verisign.com>, Jody Kolker
<jkol...@godaddy.com>
*Resent-Date: *Friday, December 9, 2022 at 9:02 AM
Hello James,
Since we are trying to get away for the placeholder text "XXXX" with
this standards-track proposal, agree option #1 makes sense to
discourage such practice. Further, agree with Jody that returning the
"redacted" rdapConformance should make it ample clear when an RDAP
server switches to the new way. That said, perhaps, we could add a
section concerning the transition from the old way to the new way if
that helps clarify.
Thanks,
Jasdip
*From: *regext <regext-boun...@ietf.org> on behalf of "Gould, James"
<jgould=40verisign....@dmarc.ietf.org>
*Date: *Friday, December 9, 2022 at 8:38 AM
*To: *"jkol...@godaddy.com" <jkol...@godaddy.com>, "kowa...@denic.de"
<kowa...@denic.de>, "draft-ietf-regext-rdap-redac...@ietf.org"
<draft-ietf-regext-rdap-redac...@ietf.org>
*Cc: *"regext@ietf.org" <regext@ietf.org>
*Subject: *Re: [regext] Review of draft-ietf-regext-rdap-redacted-09
Jody,
I thought adding the transition period to the MUST NOT would provide
for some flexibility for those that need to transition from
placeholder redaction to draft-ietf-regext-rdap-redacted, but I
believe a server would implement a hard cutover (e.g., supporting the
draft with no other form of redaction). With that in mind, I’ll
modify option 1 to be simply MUST NOT without any reference to a
transition period.
1.Keep MUST NOT – The Section 3 sentence is “The use of placeholder
text for the values of the RDAP fields, such as the placeholder text
"XXXX", MUST NOT be used for redaction.”.
2.Change MUST NOT to SHOULD NOT – This enables the draft to recommend
that placeholder text not be used for redaction, but still enable the
server to support it in parallel with the redaction methods defined in
the extension. The Section 3 sentence would become “The use of
placeholder text for the values of the RDAP fields, such as the
placeholder text "XXXX", SHOULD NOT be used for redaction.”.
3.Remove the normative language – Change the Section 3 sentence to
“The use of placeholder text for the values of the RDAP fields, such
as the placeholder text "XXXX", has been used for redaction.”.
4.Remove reference to placeholder text use for redaction – Just lead
Section 3 with the sentence “This section covers the redaction methods
that can be used with the redaction signaling defined in Section 4.2
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-redacted%23section-4.2&data=05%7C01%7Cjkolker%40godaddy.com%7C03bdff32aeb64d19ef4308daceb9b1ca%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C638049594251190871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V%2BP67JW8FHgh2fmp3u3peTK27KTc%2BMeOMQ6zIQcI8j8%3D&reserved=0>.”.
My preference is option 1 (“Keep MUST NOT”), and I agree that if the
normative language cannot remain that option 3 (“Remove the normative
language”) is the best alternative.
Can others from the working group provide their preferred option to
address Pawel’s last open feedback item? All of Pawel’s feedback will
be incorporated in draft-ietf-regext-rdap-redacted-10.
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/12zUBFrLN_pJaFUZ5m3kWDdhfCIVcFIHXnzC5UJemDrb8dOhG-s6sx98JzOdgR2thEbZuScC7bcwp01ikvhrTeW3c56Lw2T_3Cjhnt9cwZDX47IDx5uB0bys3KDVU3aImslZ_QoQrqXHB3GaDAE-u8_O1U2LM4vvlL4NH81B3tiMJ9CgWjF-p5KGZItT1BycNtLZhaPfS82uN_PYocTij06Zb5snyq30RKS0uy7pAYATiKnUOVUldIANSgrMbQfGr0d47aBUC13MGqCBJ2tnInluj0AsnzT1saj_sxfC89aQ/http%3A%2F%2Fverisigninc.com%2F>
*From: *Jody Kolker <jkol...@godaddy.com>
*Date: *Friday, December 2, 2022 at 2:27 PM
*To: *Pawel Kowalik <kowa...@denic.de>, James Gould
<jgo...@verisign.com>, "draft-ietf-regext-rdap-redac...@ietf.org"
<draft-ietf-regext-rdap-redac...@ietf.org>
*Cc: *"regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] RE: Review of draft-ietf-regext-rdap-redacted-09
My preference would be that if the server is supporting this draft
that placeholder text is not allowed to be returned for any redacted
field. I'm not sure what a transition period would look like. It
seems to me that a server is either supporting the draft with an
"rdapConformance" value of "redacted" or it's not supporting the draft
and does not return the "redacted" value in the “rdapConformance”
value. If "redacted" is returned, placeholder text should not be used.
I would support option #1 without a transition period. Servers are
free to continue with the responses used today that do not include the
“redacted” “rdapConformance” value if the server is returning
placeholder text. One the draft is supported without placeholder
text, the “redacted” “rdapConformance” value can be returned in the
responses.
However, I can live with Option #3 where the RFC acknowledges that
placeholder text has been used in the past.
Thanks,
Jody Kolker.
*From:* Pawel Kowalik <kowa...@denic.de>
*Sent:* Friday, November 25, 2022 1:50 AM
*To:* Gould, James <jgo...@verisign.com>;
draft-ietf-regext-rdap-redac...@ietf.org
*Cc:* regext@ietf.org
*Subject:* Re: Review of draft-ietf-regext-rdap-redacted-09
Caution:This email is from an external sender. Please do not click
links or open attachments unless you recognize the sender and know the
content is safe. Forward suspicious emails to isitbad@.
Hi James,
Thanks for that.
My preference would be 3 or 4, to focus the draft on signaling,
allowing the clients to recognize redacted fields.
Kind Regards,
Pawel
Am 23.11.22 um 16:57 schrieb Gould, James:
Pawel,
I add responses embedded below with “JG4 – “.
For the WG, I’m including one discussion topic at the top for
consideration:
Section 3 currently states “The use of placeholder text for the
values of the RDAP fields, such as the placeholder text "XXXX",
MUST NOT be used for redaction.” Pawel raised an issue with the
MUST NOT language and proposed to use SHOULD NOT. I view the use
of placeholder text redaction as an anti-pattern that should be
disallowed when implementing draft-ietf-regext-rdap-redacted, but
I do recognize the potential need for a transition period. I
summarize the options below:
1.Keep MJST NOT with Transition Period – Formally define the
transition period that is based on server policy in a new
Transition Considerations section.
2.Change MUST NOT to SHOULD NOT – This enables the draft to
recommend that placeholder text not be used for redaction, but
still enable the server to support it in parallel with the
redaction methods defined in the extension.
3.Remove the normative language – Change “The use of placeholder
text for the values of the RDAP fields, such as the placeholder
text "XXXX", MUST NOT be used for redaction.” To “The use of
placeholder text for the values of the RDAP fields, such as the
placeholder text "XXXX", has been used for redaction. …”.
4.Remove reference to placeholder text use for redaction – Just
lead section 3 with the sentence “This section covers the
redaction methods that can be used with the redaction signaling
defined in Section 4.2
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-redacted%23section-4.2&data=05%7C01%7Cjkolker%40godaddy.com%7C03bdff32aeb64d19ef4308daceb9b1ca%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C638049594251190871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V%2BP67JW8FHgh2fmp3u3peTK27KTc%2BMeOMQ6zIQcI8j8%3D&reserved=0>.”.
Please respond to the mailing list with your thoughts on the
options or if you have any additional options. My preferred
option is option 1 “Keep MJST NOT with Transition Period”.
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
<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fverisigninc.com%2F&data=05%7C01%7Cjkolker%40godaddy.com%7C03bdff32aeb64d19ef4308daceb9b1ca%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C638049594251190871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fP1nLiTs%2FEs8%2FG5T0nuXDr7B15JQ0%2BykFbmrJd4rMYY%3D&reserved=0>
*From: *Pawel Kowalik <kowa...@denic.de> <mailto:kowa...@denic.de>
*Date: *Wednesday, November 23, 2022 at 9:23 AM
*To: *James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>,
"draft-ietf-regext-rdap-redac...@ietf.org"
<mailto:draft-ietf-regext-rdap-redac...@ietf.org>
<draft-ietf-regext-rdap-redac...@ietf.org>
<mailto:draft-ietf-regext-rdap-redac...@ietf.org>
*Cc: *"regext@ietf.org" <mailto:regext@ietf.org> <regext@ietf.org>
<mailto:regext@ietf.org>
*Subject: *[EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09
Hi James,
My comments below.
Am 23.11.22 um 14:17 schrieb Gould, James:
[...]
JG3 – What triggered the creation of this extension was a
proposal to use placeholder text for redaction, which in my
opinion is an anti-pattern that needs to be directly
addressed. I believe that you see the need to support a
transition period that would be up to server policy. See my
comment below related to creating a Transition Considerations
section to make this explicit. The draft can define the
methods for redaction, disallow the use of placeholder text
for redaction outside of a transition period, and add explicit
support for a transition period with a set of considerations.
Does this meet your needs?
[PK3] OK, please include also this part in the Abstract and
Introduction, that the draft also defines certain rules for
redaction to mitigate the anti-patterns, if there is a consensus
in WG to mandate how redaction is done.
JG4 – I’m raising the options for discussion in the WG to
hopefully find a consensus option.
Populating the existing value with a static placeholder value as a signal for
redaction is different from what is defined for the "Redaction by Replacement Value
Method", which changes the value to a non-static value or moves the location of the
value.
[PK2] I believe it should be perfectly valid to replace one
email with another email (for example privacy proxy email)
without moving it, shouldn't it? For me it would be "Redaction
by Replacement Value Method" where both paths are same.
JG3 – Yes, use of a privacy proxy email is a form of
"Redaction by Replacement Value Method", since the real value
is not being provided but a replacement value is being used
instead. In this case the “method” value is
“replacementValue” and the “replacementPath” is not used.
Does this need to be clarified in the draft, since the intent
is to support replacing the value in place or replacing the
value using an alternate field, such as the replacement with
the “contact—uri” property?
[PK3] Now I see it from examples that replacementPath might be
omitted. It would be good to have some normative text defining that.
JG4 – Ok, I’ll look to add clarification text.
[...]
JG3 – Ok, that helps. I believe the biggest issue from a
client perspective is when they expect a non-empty value, and
the server implements the Redaction by Empty Value Method and
then returns an empty value. The use of the placeholder
redaction text can be used in parallel with
draft-ietf-regext-rdap-redacted during a transition period.
The duration of the transition period would be up to server
policy. What I don’t want to introduce is parallel forms of
redaction for beyond a transition period. How about including
the definition of a transition period in a Transition
Considerations section and updating the MUST NOT language to
“The use of placeholder text … MUST NOT be used for redaction
outside of a transition period defined in Section X . In the
Transition Considerations section, it can define that
placeholder redaction text may exist and may overlap with this
extension during a transition period that is up to server
policy. Then there can be a set of considerations for the
server and client in making the transition. I believe this
would address the transition more explicitly and leave the
timing of the transition up to server policy. Do you agree?
[PK3] If the WG is in consensus to keep "MUST NOT" then Transition
Considerations is a good way to cover the smooth transition.
JG4 – I’m raising the options for discussion in the WG to
hopefully find a consensus option.
[...]
Another approach would be to define a way of interpreting the
JSONPath
so that it is reversible or even defining a subset of JSONPath
which is
reversible in the narrower RDAP context.
JG2 - I'm not sure what is meant by JSONPath that is reversable. I
believe that JSONPath needs to be used as defined.
[PK2] Reversable means that you can unambiguously re-create
the original object structure based on the path. Normalized
JSONPath have this property (see 2.8 of JSONPath draft) but
may not be the best in case of array members identified by a
property value of array member, like in jCard. The expressions
like $.entities[?(@.roles[0]=='registrant')] can be also
reversible, but this is not true for just any JSONPath
expression. If we would define a narrowed down definition of
JSONPath expressions which are allowed, we could achieve the
property of reversibility and maybe even that one kind of
object or property would have exactly one and only possible
JSONPath describing it. Again - it's just an idea how to deal
with removed paths. It may be also not worth following if we
assume "redacted name" would be the leading property (see below).
JG3 – Thanks for the reference, I’ll review it and see whether
something can be used. My initial thought is that it’s going
to be too complex and won’t cover the broad set of use cases
in RDAP. Right now, we’ll assume that it can’t be used in
draft-ietf-regext-rdap-redacted, but it’s being reviewed.
In the end, implementing a client, I would rather want to rely
on the
"redacted name" from the "JSON Values Registry" for paths
which have
been deleted, and treating the path member as only informative.
If you agree for such processing by the client I suggest to
put it down
in the chapter 5 (maybe splitting it into server and client
side).
JG2 - From a client perspective, I believe I would first key off the
"redacted name" to route my display logic and then I would utilize a template
RDAP response overlaid with the actual response and the JSONPath to indicate the redacted
values. It would be nice to hear from some clients on this to identify useful client
JSONPath considerations.
[PK2] If I would be implementing the client likely I will do
exactly this.
JG3 – Ok, the “JSONPath Considerations” section will have two
subsections of “JSONPath Client Considerations” and “JSONPath
Server Considerations”, where the above will be the starting
JSONPath client consideration. How about the JSONPath Client
Consideration:
When the server is using the Redaction By Removal
Method (Section 3.1) or the Redaction by Replacement Value
Method (Section 3.3) with an alternate field value, the
JSONPath expression of the "path" member will not resolve
successfully with the redacted response. The client can first
key off the "name" member for display logic and utilize a
template RDAP response overlaid with the redacted response to
successfully resolve the JSONPath expression.
[PK3] OK
[...]
JG2 - Your reference to $.entities[0] is an example of an element in an array, but its'
not referring to a fixed field position of a fixed length array, such as the case for redacting the
"fn" jCard property. There is no intent to block all cases of redacting objects via the
use of an array position. Is there better language than "using the fixed field position of a
fixed length array" to provide the proper scope?
OK, now I get it. My proposal would be: "The Redaction by
Removal Method MUST NOT be used to remove an element of an
array where position of the elements in the array determines
semantic meaning of the element."
JG3 – Just a tweak, how about “The Redaction by Removal Method
MUST NOT be used to remove an element of an array where the
position of the element in the array determines semantic
meaning.”?
[PK3] Thanks.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
