While editorial errata rarely harm the ability to implement, we usually verify them if it was a clear oversight. Also this one could be confusing as one could think that there is another element…
From: Tommy Pauly <[email protected]> Date: Friday, 1. May 2026 at 06:45 To: Gorry Fairhurst <[email protected]> Cc: Michael Welzl <[email protected]>, RFC Errata System <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [Taps] Re: [Editorial Errata Reported] RFC9621 (8889) It’s editorial, and probably won’t harm anyone’s ability to implement. I can see argument for either “verified” (because it is a correct fix) or “hold for document update” (because it is editorial in nature). Gorry, I’d probably leave to you what to do based on the overhead it would cause and the effort involved on your end. Tommy On Apr 30, 2026, at 9:47 AM, Gorry Fairhurst <[email protected]> wrote: On 30/04/2026 02:35, Tommy Pauly wrote: Agreed, this looks correct, and can be verified. Thanks, Tommy So, we agree it is valid. Does this need to be called-out as a correction (i.e., The erratum is appropriate under the criteria below and should be available to implementers or people deploying the RFC) , or held for document update (The erratum is not a necessary update to the RFC. However, any future update of the document might consider it and determine whether it merits including in an update.)? Let me know, and I will verify this. Gorry On Apr 25, 2026, at 10:22 AM, Michael Welzl <[email protected]> wrote: I think this is correct. Cheers, Michael On 25 Apr 2026, at 13:30, RFC Errata System <[email protected]> wrote: The following errata report has been submitted for RFC9621, "Architecture and Requirements for Transport Services". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8889 -------------------------------------- Type: Editorial Reported by: Ingbrigt Hovind <[email protected]> Section: 4. Original Text ------------- +-----------------------------------------------------+ | Application | +-+----------------+------^-------+--------^----------+ | | | | | pre- | data | events establishment | transfer | | | establishment | termination | | | | | | | +--v------v-------v+ | +-v-------------+ Connection(s) +-------+----------+ | Transport +--------+---------+ | | Services | | | API | +-------------+ | +------------------------+--+ Framer(s) |-----------+ | +-------------+ +------------------------|----------------------------+ | Transport | | | System | +-----------------+ | | Implementation | | Cached | | | | | State | | | (Candidate Gathering) | +-----------------+ | | | | | (Candidate Racing) | +-----------------+ | | | | System | | | | | Policy | | | +----------v-----+ +-----------------+ | | | Protocol | | +-------------+ Stack(s) +----------------------+ +-------+--------+ V +-----------------------------------------------------+ | Network-Layer Interface | +-----------------------------------------------------+ Corrected Text -------------- +-----------------------------------------------------+ | Application | +-+----------------+------^-------+--------^----------+ | | | | | pre- | data | events establishment | transfer | | | establishment | termination | | | | | | | +--v------v-------v+ | +-v-------------+ Connection(s) +-------+----------+ | Transport +--------+---------+ | | Services | | | API | +-------------+ | +------------------------+--+ Framer(s) |-----------+ | +-------------+ +------------------------|----------------------------+ | Transport | | | Services | +-----------------+ | | Implementation | | Cached | | | | | State | | | (Candidate Gathering) | +-----------------+ | | | | | (Candidate Racing) | +-----------------+ | | | | System | | | | | Policy | | | +----------v-----+ +-----------------+ | | | Protocol | | +-------------+ Stack(s) +----------------------+ +-------+--------+ V +-----------------------------------------------------+ | Network-Layer Interface | +-----------------------------------------------------+ Notes ----- In figure 3 the internal implementation is referred to as a "Transport System Implementation" instead of a "Transport Services Implementation" as in the rest of the document 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. -------------------------------------- RFC9621 (draft-ietf-taps-arch-19) -------------------------------------- Title : Architecture and Requirements for Transport Services Publication Date : January 2025 Author(s) : T. Pauly, Ed., B. Trammell, Ed., A. Brunstrom, G. Fairhurst, C. S. Perkins Category : PROPOSED STANDARD Source : Transport Services Stream : IETF Verifying Party : IESG _______________________________________________ Taps mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Taps mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Taps mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Taps mailing list -- [email protected] To unsubscribe send an email to [email protected]
