Skip to main content

Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
RFC 6038

Yes

Lars Eggert

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Sean Turner)
(Tim Polk)

Note: This ballot was opened for revision 09 and is now closed.

Lars Eggert
Yes
Adrian Farrel Former IESG member
No Objection
No Objection (2010-08-11)
[See also Peter's Comment]

Section 4.2.1

There is a bit of a 2119 mess as follows...

   When simultaneously using the RECOMMENDED truncation process in TWAMP
   section 4.2.1 [RFC5357] AND Reflect octets mode, the Session-
   Reflector MUST reflect the designated octets from the Session-
   Sender's test packet in the "Packet Padding (from Session-Sender)"
   Field, and MAY re-use additional Packet Padding from the Session-
   Sender.


I think "AND" is not a 2119 term, and "RECOMMENDED" is used here simply
to report on what RFC 5357 says. How about...

   Section 4.2.1 of [RFC5356] recommends a truncation process for use in
   TWAMP. When that process is used in conjunction with the Reflect 
   octets mode, the Session-Reflector MUST reflect the designated octets
   from the Session-Sender's test packet in the "Packet Padding (from
   Session-Sender)" Field, and MAY re-use additional Packet Padding from
   the Session-Sender.

The problem with the use of "RECOMMENDED" shows up in a number of other
places. It also seems to encourage the use of other non-2119 words (such
as "IF" in Section 3.3).
Alexey Melnikov Former IESG member
No Objection
No Objection (2010-08-07)
   This field communicates the length of the padding in the TWAMP-Test Packet that
   the Session-Sender expects to be reflected, and the length of octets
   that the Session-Reflector SHALL return in include in its TWAMP-Test

This doesn't read well. I think you should either delete "return in" or "include in".

   packet format (see section 4.2).


3.4.  Additional considerations

   A Control-Client conforming to
   this extension of [RFC5357] MAY ignore the values in the higher bits
   of the Modes Field, or it MAY support other features that are
   communicated in those bit positions.  The other bits are available
   for future protocol extensions.

Is it Ok for this document to define this? I think this is already defined in the base spec.


6.2.  Registry Contents

   TWAMP Modes Registry is recommended to be augmented as follows:

   Value  Description             Semantics Definition
   0      Reserved

   1      Unauthenticated         RFC4656, Section 3.1

   2      Authenticated           RFC4656, Section 3.1

   4      Encrypted               RFC4656, Section 3.1

   8      Unauth. TEST protocol,  RFC5618, Section 3.1 (3)
          Auth. CONTROL
   16     Individual Session      RFC????, Section 3.1
          Control                 bit position (4)

Please don't repeat existing registry entries in the IANA Considerations section. The current list is maintained by IANA and any list specified in an RFC can quickly get out of date.
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
David Harrington Former IESG member
No Objection
No Objection (2010-08-11)
1) It would be helpful to include a little explanation as to why the symmetric-size option is needed, probably in paragraph 4 of section 1.
2) I'm not sure what RFC???? refers to; it this an internet-draft?
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection ()

                            
Peter Saint-Andre Former IESG member
(was Discuss) No Objection
No Objection (2010-08-10)
1. There are numerous instances of the text "the RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357]"; there is no need for the word "recommended" to be all-caps here, because the normative language already exists in RFC 5357.

2. Some of the typography is non-standard, such as "*continues*" and "IF" and "AND" and "BOTH"; it's better to provide emphasis using normal English words, such as "it is important to note that X continues" and "if and only if".
Ron Bonica Former IESG member
No Objection
No Objection (2010-08-09)
  == Unused Reference: 'RFC5226' is defined on line 738, but no explicit
     reference was found in the text
Sean Turner Former IESG member
No Objection
No Objection ()

                            
Stewart Bryant Former IESG member
No Objection
No Objection (2010-08-09)
 Nits says:

 Unused Reference: 'RFC5226' is defined on line 738, but no explicit
     reference was found in the text
Tim Polk Former IESG member
No Objection
No Objection ()