STAMP BIS

The Internet is always evolving and we want STAMP to stay current so that network operators and architects can rely on it to help them meet the needs of their users.

The extensibility built into the protocol through its Optional Extensions1 provides a light-weight means for adding new functionality as we see new opportunities for STAMP to help network operators and architects.

However, as the Internet continues to adapt, more fundamental changes may need to be made to the protocol to keep it useful. STAMP is not unique in this regard – many of the protocols managed by the IETF have undergone extensive changes over time that have resulted in new versions of the protocol (e.g., HTTP/2,2 NTPv2,3 etc.). As the protocol designers brainstorm and discuss changes that cannot easily be incorporated through the Optional Extension, they share drafts that are tagged bis, short for “again” or “twice.”4

This page will serve as a place to coordinate and store ideas, notes and drafts outlining changes that could be incorporated into a STAMPv2. We would love it if you submitted PRs to the source of this website for any items for consideration!

  Description Related Material
Session Reflector Semantics TTL of Test Packet Cannot Be Read 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. Rejected Errata, Mailing List Discussion

  1. Mirsky, Greg, Xiao Min, Henrik Nydell, Richard “Footer” Foote, Adi Masputra, and Ernesto Ruffini. 2021. “Simple Two-Way Active Measurement Protocol Optional Extensions.” Request for Comments. RFC 8972; RFC Editor. https://doi.org/10.17487/RFC8972. ↩

  2. Thomson, Martin, and Cory Benfield. 2022. “HTTP/2.” Request for Comments. RFC 9113; RFC Editor. https://doi.org/10.17487/RFC9113. ↩

  3. Martin, Jim, Jack Burbank, William Kasch, and Professor David L. Mills. 2010. “Network Time Protocol Version 4: Protocol and Algorithms Specification.” Request for Comments. RFC 5905; RFC Editor. https://doi.org/10.17487/RFC5905. ↩

  4. Oever, Niels ten, and Greg Wood. 2024. “Retiring the Tao of the IETF.” Request for Comments. RFC 9592; RFC Editor. https://doi.org/10.17487/RFC9592. ↩