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://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#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]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.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).
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
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal>
(Section
3.1
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal>)
or
the Redaction by Replacement Value Method
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value>
(Section
3.3
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value>)
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
