[ippm] Re: [Editorial Errata Reported] RFC8972 (8592)

[[e-mail]]

Hi Will, all, 

Thank you for catching this.

The suggested correction reflects the intent of the document that was approved by the IESG. The change was made during the editing phase: https://author-tools.ietf.org/iddiff?url1=draft-ietf-ippm-stamp-option-tlv-10&url2=rfc8972&difftype=--html

I will mark this one as verified.

Cheers,
Med

> -----Message d'origine-----
> De : RFC Errata System <[e-mail]>
> Envoyé : samedi 4 octobre 2025 02:41
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : [ippm] [Editorial Errata Reported] RFC8972 (8592)
> 
> 
> The following errata report has been submitted for RFC8972,
> "Simple Two-Way Active Measurement Protocol Optional Extensions".
> 
> --------------------------------------
> You may review the report below and at:
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Ferrata%2Feid8592&data=05%7C02%7Cmohamed.boucadair%40o
> range.com%7Cc68e9e0733864b4abad008de02debf36%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C638951352883049598%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=48rp9BqEJVX5%2BPure
> SQlvMZ2yDV9OZiBqcx537HJN6Q%3D&reserved=0
> 
> --------------------------------------
> Type: Editorial
> Reported by: William Hawkins <[e-mail]>
> 
> Section: 4.7
> 
> Original Text
> -------------
> A Session-Reflector might be able to put only an "SW Local" (see
> Table 9) timestamp in the Follow-Up Timestamp field.
> 
> Corrected Text
> --------------
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-option-
> tlv-02%23section-
> 4.7&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc68e9e0733864b
> 4abad008de02debf36%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 8951352883069065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%7C%7C&sdata=vxPybZSmIPJ1cOnI7o56F0H%2Bdz%2B2VK3KRDUMOabLI
> UE%3D&reserved=0)
> 
> 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.
> 
> 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.
> 
> --------------------------------------
> RFC8972 (draft-ietf-ippm-stamp-option-tlv-10)
> --------------------------------------
> Title               : Simple Two-Way Active Measurement Protocol
> Optional Extensions
> Publication Date    : January 2021
> Author(s)           : G. Mirsky, X. Min, H. Nydell, R. Foote, A.
> Masputra, E. Ruffini
> Category            : PROPOSED STANDARD
> Source              : IP Performance Measurement
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> ippm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.