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

[Mirja Kuehlewind <[e-mail]>]

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 <tpauly=[e-mail]>
Date: Friday, 1. May 2026 at 06:45
To: Gorry Fairhurst <[e-mail]>
Cc: Michael Welzl <[e-mail]>, RFC Errata System <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[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]>