[regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik <[e-mail]>]

Hi,


As an action item after IETF 115 I reviewed 
draft-ietf-regext-rdap-redacted-09 before WG LC and have the following 
questions / remarks:

Section 3, first paragraph:

 > Redaction in RDAP can be handled in multiple ways.  The use of
 > placeholder text for the values of the RDAP fields, such as the
 > placeholder text "XXXX", MUST NOT be used for redaction.  A
 > placeholder text value will not match the format requirements of each
 > of the RDAP fields and provides an inconsistent and unreliable
 > redaction signal.

Is the normative language adequate here? Firstly, I am not sure if the 
text can be well understood.
Does it mean that use of a fixed placeholder is prohibited, or any 
placeholder?
I can imagine a way of using placeholders, which do not necessarily 
break the format requirements,
therefore the second sentence shall not categorically tell "will not 
match" as it may not be even true.

My proposal would be to use SHOULD NOT instead of MUST NOT. It can be 
useful for the servers willing
still to support clients not implementing this extension in the 
transition period to populate fields with placeholders instead of just 
empty/missing fields.

---

Section 3, second paragraph:

The whole paragraph deals with particularities of redacting jCard with 
some very specific guidelines and examples.
Wouldn't it be more and future proof to have a general statement that 
redacting the data MUST NOT break the underlying data format?
The same remark applies then later to 3.2. with normative language for 
jCard redaction.

---
4.2.  "redacted" Member

The whole "redacted" member and especially the "path" and 
"replacementPath" members
shall allow the client to recognise parts of the JSON response which 
have been transformed
in the process of redaction.

Here some interesting questions:
- do the paths refer to the object before or after the redaction?
- if the paths refer to the object before the redaction, how should the 
client be able to interpret the path if not having access to this 
object, especially the JSONPath may even match multiple paths, e.g. from 
result and the path the client cannot digest which paths have been 
really removed? More to that each redaction step is actually 
transforming the object, so the order of redaction is also relevant in 
this case. Normalized Paths from JSONPath allow "reversing" the process 
from the result object if the order of redaction is being held.
- if the paths refer to the object after the redaction, likely the path 
member should be OPTIONAL not not required for redaction by removal or 
replacement, because in this case the object likely does not exist in 
the result object

With Section 5 being not-normative and about processing by the server, 
the draft should similarly include considerations for processing of the 
responses by the clients.

---

"pathLang" member

What is the rationale behind introducing this extension point? Right now 
the RFC specifies only one language, which is default one. If there will 
be an additional one I would expect it added by a RFC also answering 
some questions how to transition from one path language to another. 
Without any way for the client to express which "pathLang" it would like 
to get response with, the server would only be able to migrate after all 
clients support both formats, otherwise risking some clients to break.
And if this "pathLang" member is to persist, shouldn't there be IANA 
registry for allowed values, so that the clients have an ide what to 
implement?

---

3.1.  Redaction by Removal Method

 > The Redaction by Removal Method MUST NOT be used to remove a field
 > using the position in a fixed length array to signal the redacted
 > field.  For example, removal of an individual data field in jCard
 > [RFC7095] will result in a non-conformant jCard [RFC7095] array
 > definition.

Is the first normative sentence meant to apply to every case, or just 
the case where removal of such field would render an invalid jCard?
I think there is quite legit way or removing whole objects by position 
in a fixed length array, like "path": "$.entities[0]" which should be 
still allowed.

---

6.2.  JSON Values Registry

Registry for "redacted name" allows to identify what has been removed 
without interpreting it from the path member. This is of a great 
benefit, looking at the difficulties of interpreting the "path" member I 
mentioned above.
However, semantically, isn't this registry rather defining the members 
and objects of RDAP response in a general sense? I mean "Registry Domain 
ID" means the same no matter if in context of redaction or in context of 
RDAP response and actually IMHO we should make sure it means the same in 
any other RDAP context it would be used in the future. IMHO this IANA 
registry shall be a generic one defining labels to the information 
pieces in RDAP responses.

---

Examples with entity role indexing.

The draft has many examples of the kind 
$.entities[?(@.roles[0]=='registrant')] which might be incorrect if an 
entity holds multiple roles, as RFC9083 does not specify any particular 
order of roles in the array and also depending on the roles held by the 
entity the array might have different length. This means that 
'registrant' can be at index 0, but also at index 1. The correct 
expression would rather be with wildcard index as per 3.5.2. of 
JSONPath, like this $.entities[?(@.roles[*]=='registrant')].
The example of multiple roles shows also a tricky corner-case, as the 
server may want to redact a contact in one role but same time not redact 
it due to other role attached to the same entity. Not sure if JSONPath 
allows to express this, but this might remain an implementation detail 
of the server and not particularly a concern of this draft (apart from 
the questions to 4.2 above).

---

Re previous discussion on multiple email addresses.

Just a remark that after the last discussion on 
draft-ietf-regext-epp-eai it may be more common to have more than one 
email address. Likely RDAP needs to get EAI-aware as well on the 
response side.


Kind Regards,

Pawel