Hi James,
Thanks for posting the new version incorporating the changes. I reviewed
it and have few comments on that:
1. As the WG consensus seems to be to keep normative language in the
form "placeholder text XXXX, MUST NOT be used for redaction" I would
recommend to extend Abstract and Introduction accordingly, that the
document also specifies allowed methods of RDAP response redaction.
2. The description of "path" member in 4.3 is now correctly describing
all the cases for different redaction methods, but due to that it became
very complex. I would still reconsider, if it wouldn't be better to have
2 members "preredactedPath" and "redactedPath", which refer to
pre-redacted response and redacted response accordingly. Then for
different redaction method you would apply:
- Redaction By Removal Method: preredactedPath (OPTIONAL, same as path
in -10)
- Redaction by Empty Value Method: redactedPath (MANDATORY, same as path
in -10)
- Redaction by Partial Value Method: redactedPath (MANDATORY, same as
path in -10)
- Redaction by Replacement Value Method: preredactedPath (OPTIONAL, same
as path in -10) and redactedPath (MANDATORY, same as replacementPath in -10)
I see a clear advantage of this approach that the clients can always use
"redactedPath" on the response object without tedious logic depending on
redaction method.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
