Jim, et al,
While there is clearly work going on to determine a direction related to the
conformance values, I wanted to invest some time to give a careful review of
the current rdap-redacted draft to have it better prepared to progress after
the WG comes to some consensus.
Overall, I think that this draft looks really good. I’m hoping that we can
figure out the conformance thing soon.
In that context, and in the order of the document, here is some feedback. Most
of these are small, trending toward nit.
1. Introduction
Regarding:
A redacted RDAP field is one that has data
removed from the RDAP response due to the lack of client privilege to
receive the field.
As has been discussed elsewhere and is presented in this document, the concept
of “redaction” is broader than “removal” and also includes “edit”.
Additionally, there may be any number of reasons why a response would be
redacted (which would most certainly include “lack of client privilege”, but
could also include other reasons. To that end, I would suggest the following
edit:
A redacted RDAP field is one that has data
in the RDAP response edited due to policy, for example, the lack of client
privilege to
receive the field.
3. Redaction Methods
Regarding:
The redaction of RDAP fields fall into the two categories of
Redaction by Removal Method (Section 3.1) and Redaction by Empty
Value Method (Section 3.2), defined in the following sub-sections.
I think that this paragraph needs updating to account for (the recently added)
Section 3.3. As in:
The redaction of RDAP fields fall into the two categories of
Redaction by Removal Method (Section 3.1), Redaction by Empty
Value Method (Section 3.2), and Redaction by Replacement Value
Method (Section 3.3), defined in the following sub-sections.
3.1 Redaction by Removal Method
Nit: Suggest putting a paragraph break before “An example of redacting…” in
order to better separate the example from the normative text.
4.2 “redacted member”
Regarding:
The "redacted" member MUST be added to the RDAP response when there
are redacted fields.
Suggest that this is updated to have the MUST unambiguously cover the case when
there is exactly 1 redacted field
The "redacted" member MUST be added to the RDAP response when there
Is one or more redacted fields.
Regarding:
"method": OPTIONAL redaction method used with "removal" indicating
the Redaction By Removal Method (Section 3.1), "emptyValue"
indicating the Redaction by Empty Value Method (Section 3.2), and
"replacementValue" indicating the Redaction by Replacement Value
Method (Section 3.3). The default value is "removal" when not
provided.
I think that there is punctuation needed and a minor ed in the first line to
improve clarity. Suggested edit:
"method": OPTIONAL redaction method used; with one of the following values:
"removal" indicating
the Redaction By Removal Method (Section 3.1), "emptyValue"
indicating the Redaction by Empty Value Method (Section 3.2), and
"replacementValue" indicating the Redaction by Replacement Value
Method (Section 3.3). The default value is "removal" when not
provided.
Hope that helps. Questions welcome.
Thanks
Rick
From: regext <[email protected]> on behalf of [email protected]
<[email protected]>
Date: Thursday, May 26, 2022 at 1:46 PM
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt
CAUTION: This email came from outside your organization. Don’t trust emails,
links, or attachments from senders that seem suspicious or you are not
expecting.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the
IETF.
Title : Redacted Fields in the Registration Data Access Protocol (RDAP) Response
Authors : James Gould
David Smith
Jody Kolker
Roger Carney
Filename : draft-ietf-regext-rdap-redacted-07.txt
Pages : 37
Date : 2022-05-26
Abstract:
This document describes an RDAP extension for explicitly identifying
redacted RDAP response fields, using JSONPath as the default
expression language.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/<https://protect-us.mimecast.com/s/ocBQC0RPwLiGp2VCOzYRs?domain=datatracker.ietf.org>
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-redacted-07.html<https://protect-us.mimecast.com/s/YCfQCgJNR2fADl9H7GDCZ?domain=ietf.org>
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-redacted-07<https://protect-us.mimecast.com/s/_x_zCjRNX8inVj8Cjhvdu?domain=ietf.org>
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/whMrCkRNY7iOPn9SNnQJU?domain=ietf.org>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
