Thanks everyone that provided their preference for the options on the use of
redaction by placeholder text. The following is a breakdown of the preferences
(first - #1, second - #2, and third - #3) based on the responses received:
1. Keep MUST NOT
* Jim Gould #1
* Jody Kolker #1
* Jasdip Singh #1 – Please confirm this is your true #1, since elements
of option 5 were also referenced in your response
* Mario Loffredo #1
* Andy Newton #1
* Dan Keathley #1
2. Change MUST NOT to SHOULD NOT
* None
3. Remove the normative language
* Pawel Kowalik #1
* Jody Kolker #2
* Jim Gould #3
4. Remove reference to placeholder text use for redaction
* Pawel Kowalik #2
5. Keep MUST NOT with Transition Considerations section
* Jim Gould #2
* Jasdip Singh #2
At this point draft-ietf-regext-rdap-redacted-10 will keep the MUST NOT
language, pending any additional responses or options.
draft-ietf-regext-rdap-redacted-10 will be posted that includes Pawel Kowalik’s
feedback and Mario Loffredo’s feedback. The new “Redaction by Partial Value
Method” will be added based on Mario Loffredo’s feedback.
Thanks,
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 12/14/22, 4:57 PM, "Keathley, Daniel" <[email protected]> wrote:
+1 for option 1.
--Dan
On 12/13/22, 9:31 AM, "regext on behalf of Andrew Newton"
<[email protected] on behalf of [email protected]> wrote:
Caution: This email originated from outside the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
I think Jody captured my thoughts. Option 1 is my preference.
-andy
On Fri, Dec 9, 2022 at 12:33 PM Mario Loffredo
<[email protected]> wrote:
>
> Hi James and others,
>
> I prefer option 1 too.
>
> With regard to the transition period, think it can't really be
implemented since this specification doesn't describe features for a server to
swtich from one way to and back from the other on demand until the old way is
completely deprecated. As opposed to the replacement of jCard with JSContact,
in this case it's not worth it because basically it doesn't make much
difference for a client if an RDAP field is missing or contains a placeholder
value.
>
> What a server can do is to notify the clients about the imminent
change of redaction strategy and then make the switch when it's time.
>
> Best,
>
> Mario
>
> Il 09/12/2022 15:30, Gould, James ha scritto:
>
> 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://secure-web.cisco.com/1W2fXVOH_5_TikpsQ6Z8tBYK_87TJMLAKMNijY5Q1PGkDrUWmCrx8F9cJt5du66V0ULUGUpdgkMTOSUBoDaPsh6htrVn6XxNJYcqcqnu_nMBKp8ASBJGsDg8KX82CO3_EK6UbxXDf-XNDIoosqRc5Nh_TigXNN58U5lg9nevht7BmHW6YWjIbTMWsuV_sc7JIUZOaPmegkJ7S2vYWtq--wN4BFB-Kf3Wr_UrIcvCRJSrsdI-sIk_V0poe945FEcJiRg7LpTIoc2R8rvPsCSoX2iRYEmEcnH0NEkDcTfODYSE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-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.”.
>
> 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
> [email protected]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
>
>
>
> From: Jasdip Singh <[email protected]>
> Date: Friday, December 9, 2022 at 9:02 AM
> To: "Gould, James" <[email protected]>, Jody
Kolker <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: [EXTERNAL] Re: [regext] Review of
draft-ietf-regext-rdap-redacted-09
> Resent-From: <[email protected]>
> Resent-To: David Smith <[email protected]>, Roger Carney
<[email protected]>, James Gould <[email protected]>, Jody Kolker
<[email protected]>
> 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 <[email protected]> on behalf of "Gould, James"
<[email protected]>
> Date: Friday, December 9, 2022 at 8:38 AM
> To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
> Cc: "[email protected]" <[email protected]>
> 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.”.
>
>
>
> 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
> [email protected]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
>
>
>
> From: Jody Kolker <[email protected]>
> Date: Friday, December 2, 2022 at 2:27 PM
> To: Pawel Kowalik <[email protected]>, James Gould
<[email protected]>, "[email protected]"
<[email protected]>
> Cc: "[email protected]" <[email protected]>
> 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 <[email protected]>
> Sent: Friday, November 25, 2022 1:50 AM
> To: Gould, James <[email protected]>;
[email protected]
> Cc: [email protected]
> 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.”.
>
>
>
> 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
> [email protected]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
>
>
>
> From: Pawel Kowalik <[email protected]>
> Date: Wednesday, November 23, 2022 at 9:23 AM
> To: James Gould <[email protected]>,
"[email protected]"
<[email protected]>
> Cc: "[email protected]" <[email protected]>
> 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)
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
