The following errata report has been rejected for RFC9537, "Redacted Fields in the Registration Data Access Protocol (RDAP) Response".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8004 -------------------------------------- Status: Rejected Type: Technical Reported by: James Gould <jgo...@verisign.com> Date Reported: 2024-06-26 Rejected by: Orie Steele (IESG) Section: GLOBAL Original Text ------------- This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. Corrected Text -------------- This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields. Notes ----- The Abstract and the first sentence of the Introduction is "This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.". This sentence is combining two aspects into a single sentence ("explicitly identifying redacted RDAP response fields" and "using JSONPath as the default expression language") incorrectly. It is true that the extension is "explicitly identifying redacted RDAP response fields" and it's true that extension is "using JSONPath as the default expression language", but the expression languages are optional and the use of JSONPath as the default expression language is not relevant for the Abstract and first sentence of the Introduction. The recommended change is to remove the ", using JSONPath as the default expression language" from the sentences to correct it, resulting in: "This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields." --VERIFIER NOTES-- Per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ I considered HFDU based on: >Technical items that have a clear resolution in line with the original intent >should be classified as Verified. If the resolution is not clear or requires >further discussion, the report should be classified as Hold for Document >Update. In both cases, only items that are clearly wrong should be considered. However, it is not obvious to me that this is "clearly wrong". >The erratum is invalid or proposes a significant change to the RFC that should >be done by publishing a new RFC that replaces or updates the current one. In >the latter case, if the change is to be considered for future updates of the >document, it should be proposed using channels other than the errata process, >such as a WG mailing list. It seems to me that the correct solution is a -bis document, especially if the intention is to clarify mandatory or optional implementation details that impact interoperability. -------------------------------------- RFC9537 (draft-ietf-regext-rdap-redacted-16) -------------------------------------- Title : Redacted Fields in the Registration Data Access Protocol (RDAP) Response Publication Date : March 2024 Author(s) : J. Gould, D. Smith, J. Kolker, R. Carney Category : PROPOSED STANDARD Source : Registration Protocols Extensions Stream : IETF Verifying Party : IESG _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
