As this is reported as editorial and we are agreeing to that, RFC editor will take care of it. ( by the way, RFC editor has not flagged that they need input to resolve it )
// Zahed On Fri, May 1, 2026 at 06:44 Tommy Pauly <[email protected]> wrote: > 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] > 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] To unsubscribe send an email to [email protected]
