[Taps] Re: [Editorial Errata Reported] RFC9621 (8889)

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>>> 
>>> I think this is correct.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> 
>>>> On 25 Apr 2026, at 13:30, RFC Errata System <[e-mail]> 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 <[e-mail]>
>>>> 
>>>> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> _______________________________________________
>>> Taps mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> Taps mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>