[ippm] Re: [Technical Errata Reported] RFC8762 (8518)

[[e-mail]]

Hi Will, 

Thank you for filling this.

My current take is to reject it as this errata is not the right approach to add new behavior. 

You may consider writing a short draft to add that clarification. This would also allow the WG to discuss whether there are other mans to achieve this. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Will Hawkins <[e-mail]>
> Envoyé : mardi 22 juillet 2025 23:22
> À : RFC Errata System <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: [Technical Errata Reported] RFC8762 (8518)
> 
> 
> As I have said before, I sincerely appreciate all the work that you
> all have put into defining STAMP. When I started the Teaparty
> implementation with no prior exposure to the protocol, the precision
> of your language made my job very easy. I hope that this report is
> helpful.
> 
> Prior to filing, I spoke to Greg and he suggested that I submit the
> report -- I would never have assumed that an actual error existed
> without first speaking to an expert. That said, I do not mean to
> imply that Greg has already confirmed this errata.
> 
> Again, I hope that this report is helpful.
> 
> Sincerely,
> Will
> 
> On Tue, Jul 22, 2025 at 5:18 PM RFC Errata System <rfc-editor@rfc-
> editor.org> wrote:
> >
> > The following errata report has been submitted for RFC8762,
> "Simple
> > Two-Way Active Measurement Protocol".
> > Type: Technical
> > Reported by: Will Hawkins <[e-mail]>
> >
> > Section: 4.3.1-4.5
> >
> > Original Text
> > -------------
> > The Session-Sender TTL field is one octet long, and its value is
> the
> > copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the
> received
> > STAMP-Test packet.
> >
> > Corrected Text
> > --------------
> > The Session-Sender TTL field is one octet long, and its value is
> the
> > copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the
> received
> > STAMP-Test packet. If an implementation cannot fetch the actual
> TTL
> > value from the TTL field (or Hop Limit) in the IP header of the
> > received STAMP-Test packet, it MUST set the Session- Sender TTL
> value
> > as 255.
> >
> > Notes
> > -----
> > The RFC contains no language describing the value that the
> reflector should include in the Session Sender TTL field of a
> reflected STAMP packet if the TTL value cannot be read from the IP
> header of the test packet. The language seems to presume that
> fetching the TTL is always possible. Having a description for the
> behavior of an implementation when that is not the case would help
> the life of the implementer.
> >
> > As an added benefit of defining the behavior in the "error case",
> there would be an increase in the compatibility between STAMP and
> TWAMP Light. TWAMP Light, as a result of its reliance on TWAMP,
> specifies the behavior of an implementation that cannot fetch the
> TTL value from a test packet (and is the source of the suggested
> language given above).
> >
> > 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.
> >
> > --------------------------------------
> > RFC8762 (draft-ietf-ippm-stamp-10)
> > --------------------------------------
> > Title               : Simple Two-Way Active Measurement Protocol
> > Publication Date    : March 2020
> > Author(s)           : G. Mirsky, G. Jun, H. Nydell, R. Foote
> > Category            : PROPOSED STANDARD
> > Source              : IP Performance Measurement
> > Stream              : IETF
> > Verifying Party     : IESG
____________________________________________________________________________________________________________
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.