Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
draft-ietf-ippm-twamp-reflect-octets-09

[Ballot comment]
[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).

[Ballot comment]
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?

[Ballot comment]
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".

[Ballot discuss]
This specification states that "the Reflect octets mode re-designates the original TWAMP-Test (and OWAMP-Test) Packet Padding Field (see section 4.1.2 of [RFC4656])".  Therefore it appears that this specification formally updates RFC 4656. However, the document header notes only that it updates RFC 5357.

[Ballot comment]
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.

IANA comments:

Upon approval of this document, IANA will make the following assignments
in the "Two-way Active Measurement Protocol (TWAMP) Parameters" registry
located at
http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml
sub-registry "TWAMP-Modes"

Value Description Semantics Definition Reference
----- ----------- -------------------- ---------
tbd(32) Reflect Octets section 3.1 [RFC-ippm-twamp-reflect-octets-07]
Capability new bit position (5)
tbd(64) Symmetrical Size section 3.1 [RFC-ippm-twamp-reflect-octets-07]
Sender Test Packet Format new bit position (6)


We understand the above to be the only IANA Action for this document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document sheperd is Henk Uijterwaal. He would not have bothered to write
this note if he didn't believe that the document was ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

This is a small feature request. About half a dozen people have read the
document and confirmed that this request will work without affecting current
implementations. The request itself seems to be a useful enhancement.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

No, there are no such concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Decent, with some 6 members of the group reviewing it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits?

There is a reference to RFC5226 which is not used anywhere. THis
can be removed by the editor.

(1.h) Has the document split its references into normative and
informative?

Yes
Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

No

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes, it appears to be correct.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes two
closely-related features for TWAMP: an optional capability where the
responder host returns some of the command octets or padding octets
to the controller, and an optional sender packet format that ensures
equal test packet sizes are used in both directions.


Working Group Summary
The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noticing.

Document Quality
Good