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]
