RFC Errata
Found 6 records.
Status: Verified (6)
RFC 5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008
Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545
Source of RFC: ippm (ops)
Errata ID: 1587
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14
Section 3.5, pg.10 says:
<< last paragraph of 3.5 >>
When the requested Receiver Port is not available (e.g., port in
use), the Server at the Session-Reflector MAY suggest an alternate
and available port for this session in the Port field. The Session-
Sender either accepts the alternate port, or composes a new Session-
| Request message with suitable parameters. Otherwise, the Server at
vvvvvvvvvvvvvvvvvv !!!!!!!!!!^^^
| the Control-Client uses the Accept field to convey other forms of
| session rejection or failure and MUST NOT suggest an alternate port;
^
in this case, the Port field MUST be set to zero.
It should say:
When the requested Receiver Port is not available (e.g., port in
use), the Server at the Session-Reflector MAY suggest an alternate
and available port for this session in the Port field. The Session-
Sender either accepts the alternate port, or composes a new Session-
| Request message with suitable parameters. Otherwise, the Server uses
^
| the Accept field to convey other forms of session rejection or
| failure to the Control-Client and MUST NOT suggest an alternate port;
^^^^^^^^^^^^^^^^^^^^^^^
in this case, the Port field MUST be set to zero.
Notes:
The original description does not match the architectural model depicted
in the figure in Section 1.2 (page 4), where the Server and the
Control-Client are distinct entities, and the TWAMP-Control messages
flow between these parties.
The proposed corrected text aims to clarify the roles.
Errata ID: 1589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14
Section 4.2.1, pg.16 says:
<< headline for figure on page 16 >> | For authenticated and encrypted modes:
It should say:
| Plaintext format for authenticated and encrypted modes: ^^^^^^^^^^^^^^^^^^
Notes:
The original headline is misleading; it does *not* show the general
on-the-wire format, which is partially hidden by encryption.
Thus, the headline should be amended to avoid confusion.
Errata ID: 1590
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14
Section 4.2.1, pg.17 says:
<< second paragraph on page 17 >> Sequence Number is the sequence number of the test packet according | to its transmit order. It starts with zero and is incremented by one | for each subsequent packet. The Sequence Number generated by the Session-Reflector is independent from the sequence number of the arriving packets.
It should say:
Sequence Number is the sequence number of the test packet according
| to its transmit order within the TWAMP test session. It starts with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| zero and is incremented by one for each subsequent packet in the
vvvvvvv ^^^^^^^^
| session. The Sequence Number generated by the Session-Reflector is
independent from the sequence number of the arriving packets.
Notes:
In the original text, it remains unclear whether this sequence number
is maintained per session, per Session-Sender, or per Session-Reflector.
Appendix I, in the 3rd text paragraph on page 23, seems to give
a hint that the Session-Reflector generated sequence numbers might
have been intended to be generated independently per *session*.
Since similar behavior is not present in OWAMP, it ugently needs to
be specified in RFC 5357 to further interoperable implementations.
The corrected text proposed aims at cure this deficiency via a change
with minimal footprint.
Errata ID: 1593
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14
Section 8.1 and 8.2 says:
<< Section 8.1, on top of page 22 >>
IANA has created a TWAMP-Control Command Number registry. TWAMP-
| Control commands are specified by the first octet in OWAMP-Control
!!!!!!!!!!!!!!!
messages as shown in Section 3.5 of [RFC4656], and modified by this
| document. Thus, this registry may contain sixteen possible values.
^^^^^^^
It should say:
IANA has created a TWAMP-Control Command Number registry. TWAMP-
Control commands are specified by the first octet in OWAMP-Control
messages as shown in Section 3.5 of [RFC4656], and modified by this
| document. Thus, this registry may contain 256 possible values.
^^^
Notes:
Dependent second instance of the issue:
According to the quoted snippet from Section 8.1, Section 8.2 again
uses "may only contain sixteen values", which should be corrrected
in the same manner.
Rationale:
Apparently, "the first octet" will allow *256* possible values, not 16.
Therefore, without an explanation of why only 16 values are allowed,
this restriction does not make sense.
In to the lack of an explanation for the restriction, the RFC text
and the IANA registry should be changed, replacing "sixteen" by "256"
throughout.
Alternatively, a clarifying note would have to be supplied, in order
to justify the restriction.
Hint: Errata Note entered on request of the responsible AD before
resolution with the authors.
Errata ID: 5045
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04
Section 4.2.1 says:
The minimum data segment length of TWAMP-Test packets in unauthenticated mode is 41 octets, and 104 octets in both authenticated mode and encrypted modes.
It should say:
The minimum data segment length of TWAMP-Test packets in unauthenticated mode is 41 octets, and 112 octets in both authenticated mode and encrypted modes.
Notes:
In authenticated/encrypted mode, the minimum data segment length should be 112 octets, instead of 104 octets.
Errata ID: 5046
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2018-11-28
Section 4.1.2 says:
each direction of transmission (this is usually desirable). To compensate for the Reflector's larger test packet format, the Sender appends at least 27 octets of padding in unauthenticated mode, and at least 56 octets in authenticated and encrypted modes.
It should say:
each direction of transmission (this is usually desirable). To compensate for the Reflector's larger test packet format, the Sender appends at least 27 octets of padding in unauthenticated mode, and at least 64 octets in authenticated and encrypted modes.
Notes:
In authenticated/encrypted mode, the minimum data segment length of TWAMP-Test and OWAMP-Test packets is 112 octets and 48 octets respectively, so the Sender should append at least 64 octets, instead of 56 octets.