Subject: [ippm] [Errata Verified] RFC6038 (6408)

From: RFC Errata System <[email-masked]>
Date: Mon, 25 Jan 2021 17:04:59 -0800 (PST)

The following errata report has been verified for RFC6038,
"Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6408

--------------------------------------
Status: Verified
Type: Technical

Reported by: Nikolai Malykh <[email-masked]>
Date Reported: 2021-01-25
Verified by: Martin Duke (IESG)

Section: 5.1.3

Original Text
-------------
   When using the truncation process in TWAMP alone, see Section 4.2.1
   of [RFC5357], the Session-Sender MUST append sufficient Packet
   Padding octets to allow the same IP packet payload lengths to be used
   in each direction of transmission (this is usually desirable).  To
   compensate for the Session-Reflector's larger test packet format, the
   Session-Sender MUST append at least 27 octets of padding in
   Unauthenticated mode, and at least 56 octets in Authenticated and
   Encrypted modes.  The sizes of TWAMP-Test protocol packets and the
   resulting truncated padding to achieve equal packet sizes in both
   directions are shown in the table below:

Morton & Ciavattone          Standards Track                   [Page 11]

RFC 6038             Reflect Octets & Symmetric Size        October 2010

    +-------------------+----------------------+---------------------+
    | Octets in:        | Unauthenticated Mode | Auth/Encrypted Mode |
    +-------------------+----------------------+---------------------+
    | Reflector Header  | 41                   | 104                 |
    | Sender Header     | 14                   | 48                  |
    | Truncated Padding | 27                   | 56                  |
    +-------------------+----------------------+---------------------+

                       TWAMP-Test Padding Truncation

   When using the Reflect Octets mode simultaneously with the truncation
   process that TWAMP recommends in Section 4.2.1 of [RFC5357], the
   Session-Sender MUST append at least 27 octets of padding plus the
   Length of the padding to reflect octets when operating in
   Unauthenticated mode.  The Session-Sender MUST append at least 56
   octets of padding plus the Length of the padding to reflect octets
   when operating in Authenticated and Encrypted modes.

Corrected Text
--------------
   When using the truncation process in TWAMP alone, see Section 4.2.1
   of [RFC5357], the Session-Sender MUST append sufficient Packet
   Padding octets to allow the same IP packet payload lengths to be used
   in each direction of transmission (this is usually desirable).  To
   compensate for the Session-Reflector's larger test packet format, the
   Session-Sender MUST append at least 27 octets of padding in
   Unauthenticated mode, and at least 64 octets in Authenticated and
   Encrypted modes.  The sizes of TWAMP-Test protocol packets and the
   resulting truncated padding to achieve equal packet sizes in both
   directions are shown in the table below:

Morton & Ciavattone          Standards Track                   [Page 11]

RFC 6038             Reflect Octets & Symmetric Size        October 2010

    +-------------------+----------------------+---------------------+
    | Octets in:        | Unauthenticated Mode | Auth/Encrypted Mode |
    +-------------------+----------------------+---------------------+
    | Reflector Header  | 41                   | 112                 |
    | Sender Header     | 14                   | 48                  |
    | Truncated Padding | 27                   | 64                  |
    +-------------------+----------------------+---------------------+

                       TWAMP-Test Padding Truncation

   When using the Reflect Octets mode simultaneously with the truncation
   process that TWAMP recommends in Section 4.2.1 of [RFC5357], the
   Session-Sender MUST append at least 27 octets of padding plus the
   Length of the padding to reflect octets when operating in
   Unauthenticated mode.  The Session-Sender MUST append at least 64
   octets of padding plus the Length of the padding to reflect octets
   when operating in Authenticated and Encrypted modes.

Notes
-----
Incorrect header sizes (104 instead of 112) and the required padding size (56 instead of 64) for modes with authentication and encryption.

--------------------------------------
RFC6038 (draft-ietf-ippm-twamp-reflect-octets-09)
--------------------------------------
Title               : Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
Publication Date    : October 2010
Author(s)           : A. Morton, L. Ciavattone
Category            : PROPOSED STANDARD
Source              : IP Performance Measurement
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: tom petch <[email-masked]>
Date: Tue, 26 Jan 2021 10:09:58 +0000

Looking at this I-D, I see that earlier versions defined Identifier as 16-bit integer range 0 to 65535 with 64512 to 65536 reserved for private use

which is obviously a mistake.

The current version has

   The Registered Performance Metric unique identifier is an unbounded
   integer (range 0 to infinity).

   The Identifier 0 should be Reserved.  The Identifier values from
   64512 to 65536 are reserved for private or experimental use, and the
   user may encounter overlapping uses.

which is not obviously a mistake but I suspect that it still is one.

Tom Petch

---

From: tom petch <[email-masked]>
Date: Tue, 26 Jan 2021 10:38:29 +0000

Reading on ....
________________________________________
From: ippm <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 26 January 2021 10:09

The current version has

<tp>
.... I see the Revision is defined in
7.5.3.  Revision
   The revision number of a Registered Performance Metric, starting at 0

and again

8.2.  Revising Registered Performance Metrics
...
Each Registered Performance Metric in the Performance Metrics
   Registry has a revision number, starting at zero. 

but in 

11.5.3.  Revision
   <1.0>

which is not what I think of as zero.  It also begs the question of this being a major and minor revision number which it looks like to me but is not mentioned elsewhere.

Tom Petch
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm