Found 4 records.

Status: Verified (4)

RFC 8972, "Simple Two-Way Active Measurement Protocol Optional Extensions", January 2021

Errata ID: 8339
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2025-03-18
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-25

Section 4.7 says:

The Session-Reflector MUST validate the Length value of the STAMP test
packet.

It should say:

The Session-Reflector MUST validate the Length value of the
Follow-Up Telemetry TLV in that STAMP test packet.

Notes:

--- Verifier note ---
Updated the type of errata to technical from editorial.

There is no length field discussed for the test packet. The behavior is about checking the length of a Follow-Up Telemetry TLV included in a test packet.

Errata ID: 8199
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2024-12-04
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-12-04

Section 4.4 says:

Also, the Session-Reflector MUST copy the value of the DSCP and ECN
fields of the IP header of the received STAMP test packet into the
DSCP2 field in the reflected test packet.

It should say:

Also, the Session-Reflector MUST copy the value of the DSCP and ECN
fields of the IP header of the received STAMP test packet into the
DSCP2 and ECN fields, respectively, in the reflected test packet.

Notes:

First, thank you to all the IETF contributors who do such amazing work to keep the Internet going (seriously!). I noticed this minor omission while implementing the specification. I spoke with Mr. Mirsky (one of the authors) who suggested I file this report. Of course, the authors' intent is not in doubt, but he suggested that I submit this report nonetheless. Besides this very minor misstatement, as someone writing an implementation who was completely uninvolved in drafting the RFC, I have found this document to be incredibly readable and easy to follow -- thank you!

[Edit: WK (Ops AD): Thanks for the Errata (and the kind note) ].

Errata ID: 8591
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2025-10-03
Verifier Name: Mohamed Boucadair
Date Verified: 2025-10-07

Section 4.3 says:

Timestamp In:  A one-octet field that characterizes the method by
   which the ingress of the Session-Reflector obtained the timestamp
   T2.  A timestamp may be obtained with hardware assistance via a
   software API from a local wall clock or from a remote clock (the
   latter is referred to as a "control plane").  Table 9 lists the
   possible values.

Sync Src Out:  A one-octet field that characterizes the source of
   clock synchronization at the egress of the Session-Reflector.
   Table 7 lists the possible values.

Timestamp Out:  A one-octet field that characterizes the method by
   which the egress of the Session-Reflector obtained the timestamp
   T3.  Table 9 lists the possible values.

It should say:

Timestamp In:  A one-octet field that characterizes the method by
   which timestamps are obtained at the ingress of the 
   Session-Reflector.
   A timestamp may be obtained with hardware assistance via a
   software API from a local wall clock or from a remote clock (the
   latter is referred to as a "control plane").  Table 9 lists the
   possible values.

Sync Src Out:  A one-octet field that characterizes the source of
   clock synchronization at the egress of the Session-Reflector.
   Table 7 lists the possible values.

Timestamp Out:  A one-octet field that characterizes the method by
   which timestamps are obtained at the egress of
   the Session-Reflector. Table 9 lists the possible values.

Notes:

First, and as usual, I sincerely appreciate the technical accuracy of the authors of the STAMP-related RFCs. As an implementer, the writing and specificity make it easy to build compliant software. I hope that this errata report is helpful for future implementers.

Second, I apologize for not knowing the best way to refer to two, non contiguous phrases from the same section that both require changes. I hope that what I have included makes it obvious what needs to be changed.

I have conferred with one of the RFC's authors who indicated that the inclusion of T2 and T3 were simply the result of an error in drafting. We collaborated via email to arrive at the corrected text I have submitted here. I say that only to indicate that I have attempted to do enough research prior to submitting this report so that it is not a waste of time but _not_ to imply that the person with whom I communicated endorses this report.

Thank you again for your work!
Will

==Verifier Note

See https://mailarchive.ietf.org/arch/msg/ippm/t4-ZrPhTKo6JCaApOTfBJUA-w9s/

Errata ID: 8592
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2025-10-04
Verifier Name: Mohamed Boucadair
Date Verified: 2025-10-07

Section 4.7 says:

A Session-Reflector might be able to put only an "SW Local" (see
Table 9) timestamp in the Follow-Up Timestamp field.

It should say:

A Session-Reflector might be able to put only an "SW Local" (see
Table 9) timestamp in the Timestamp field of the reflected STAMP
packet (Figure 2).

Notes:

Sorry for the back-to-back submissions -- I had these queued up and had delayed submission.

In an earlier version of the RFC, the sentence quoted in the Original Text read

"A Session-Reflector might be able to put in the Timestamp field only a "SW Local" (see Table 6) timestamp."

(see, inter alia, https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-option-tlv-02#section-4.7)

I have confirmed with one of the draft's original authors that a simple copy editing error was the cause of this tiny mistake. The sentence at the beginning of section 4.7 is meant to refer to the Timestamp field in the STAMP packet transmitted by the Session Reflector.

The earlier draft of this RFC specified that what is currently named the Follow-Up Timestamp field should be named the Timestamp field. The name collision resulted in an overzealous search/replace hiccup. I hope that having the record reflect the correct field name will save future developers from having to scratch their head like I did.

As usual, I sincerely appreciate the technical accuracy of the authors of the STAMP-related RFCs. As an implementer, the writing and specificity make it easy to build compliant software. I hope that this errata report is helpful for future implementers.

==Verifier note

See https://mailarchive.ietf.org/arch/msg/ippm/_sK9708NnI79IRif4AFN8LmmkZs/

Report New Errata