Hello all, I asked one of our developers at GoDaddy to implement the Redacted RFC with the changes that were included in the Errata. He was able to implement the RFC with the proposed redaction as GoDaddy would be using it with redaction by empty value and redaction by replacement in under two hours. He stated that GoDaddy's case is pretty simple and the RFC was straightforward to implement.
Has anyone else tried to implement the RFC with the additional Errata? Thanks, Jody Kolker 319-329-9805 (mobile) Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. -----Original Message----- From: RFC Errata System <rfc-edi...@rfc-editor.org> Sent: Thursday, June 27, 2024 5:26 AM To: jgo...@verisign.com; dsm...@verisign.com; Jody Kolker <jkol...@godaddy.com>; Roger Carney <rcar...@godaddy.com>; superu...@gmail.com; orie@transmute.industries; gal...@elistx.com; i...@antoin.nl Cc: jgo...@verisign.com; regext@ietf.org; rfc-edi...@rfc-editor.org Subject: [regext] [Technical Errata Reported] RFC9537 (8006) Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. The following errata report has been submitted 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/eid8006 -------------------------------------- Type: Technical Reported by: James Gould <jgo...@verisign.com> Section: 4.2 Original Text ------------- The "postPath" member MUST be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4). Corrected Text -------------- The "postPath" member MAY be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4). Notes ----- The "postPath" member is an OPTIONAL member and this MUST can provide confusion. The intent of this sentence was to outline which of the path members ("prePath", "postPath", and "replacementPath") to use when using path expressions and not to conflict with the OPTIONAL definition. All of the path expression members are defined as OPTIONAL in the RFC, so this MUST needs be changed to a MAY to correct the confusion. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- 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 _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
