Subject: [ippm] [Editorial Errata Reported] RFC5357 (3511)

From: RFC Errata System <[email-masked]>
Date: Fri, 8 Mar 2013 06:02:15 -0800 (PST)

The following errata report has been submitted for RFC5357,
"A Two-Way Active Measurement Protocol (TWAMP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5357&eid=3511

--------------------------------------
Type: Editorial
Reported by: Steve Baillargeon <[email-masked]>

Section: Appendix

Original Text
-------------
              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |<----------------->|                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder.  The responder follows the
   Session-Reflector behavior of TWAMP as described in section 4.2 with
   the following exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics.  This architecture allows for collection of two-way metrics.

Corrected Text
--------------
              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |                   |                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder. Other examples are also
   possible. For instance, the responder may include a light Server
   responsible to instantiate the test session states based on the
   received test packets. The responder follows the Session-Reflector
   behavior of TWAMP as described in section 4.2 with the following
   exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics. This architecture allows for collection of two-way metrics.
   Otherwise IF the Session- Reflector has knowledge of the session
   state (using inspection of the received test packets for instance),
   THEN the Session-Reflector MUST generate it is own sequence number
   for each reflected packet.  The controller receives the reflected
   test packets and collects two-way and one-way metrics.  This
   alternative allows for collection of two-way and one-way metrics with
   TWAMP Light.

Notes
-----
Many readers of the appendix don't understand the meaning of informative and try to interpret the TWAMP light description as a specification. To correct this problem, it is recommended to add a few more lines explaning other TWAMP light architectures are possible. The original text describes a single TWAMP light architecture and this is misleading.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5357 (draft-ietf-ippm-twamp-09)
--------------------------------------
Title               : A Two-Way Active Measurement Protocol (TWAMP)
Publication Date    : October 2008
Author(s)           : K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz
Category            : PROPOSED STANDARD
Source              : IP Performance Metrics
Area                : Transport
Stream              : IETF
Verifying Party     : IESG