Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)
RFC 5938

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

(Lars Eggert) Yes

(Jari Arkko) No Objection

Comment (2010-04-07 for -)
No email
send info
I support Sean's Discuss, and the spec needs to point back to the
original RFCs so that the semantics of HMAC and other fields are
adequately specified for the new commands.

Secondly, I found this text a bit odd:

   o  If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be
      enforced when any test session is in-progress (started and not

The text should probably read "If the REFWAIRT timer is implemented ..."
Earlier text already recommends REFWAIT to be implemented, it should
not be repeated here.

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-04-06)
No email
send info
A few nits you might sort out along the way...

I don't think that using 2119 language in the Abstract or Introduction
is very appropriate. That language is really intended for specifying
protocol behavior.


Section 1

   This memo is intended to be an update to the TWAMP core protocol
   specified in [RFC5357].  It is not required to implement the feature
   described in this memo to claim compliance with [RFC5357].

It is a bit late for intentions :-)
I think this is an update fair and square.

The second sentence could also do with some polish. What is not required
to implement the feature?


It is not immediately clear to me whether this feature also applies to
OWAMP. I think not, so it is slightly confusing that Section 1 says...

   This memo describes an OPTIONAL feature for TWAMP.  TWAMP (and OWAMP)
   start all previously requested and accepted test sessions at once.


Section 2

   The scope of the memo is currently limited to specifications of the
   following features:

So at what point might it change?


My Discuss used to read...
A small issue I would like to clarify before supporting the publication of this document. In Section 1 you have...

   Implementers of this feature may also wish to implement the "Reflect
   Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets],
   once it has been published as an RFC.  This feature allows a Control-
   Client to insert a locally-specified request number into the Request-
   TW-Session command (in octets originally designated MBZ=Must Be
   Zero), and a compliant Server will return the request number in its
   reply (Accept message).  The Reflect Octets feature makes multiple
   simultaneous session requests possible, and supports the operation of
   many simultaneous test sessions (similar to the goal of this memo).

Do I read this to mean that the working group is developing two
solutions to the same problem? One (the other) having wider 

Can you clarify the working group thinking on this?

- Al has clarified for me that there is no overlap between the 
- work, but it would be really nice if the quoted paragraph
- could be rewritten to avoid implying that there are two
- different solutions to the same problems.

(David Harrington) No Objection

Comment (2010-04-06 for -)
No email
send info
A couple minor edits:
s/must be one or greater/MUST be one or greater/g
s/one or more the sessions/one or more of the sessions/g

(Russ Housley) No Objection

Alexey Melnikov No Objection

Comment (2010-04-03 for -)
No email
send info
3.2.  Start-N-Sessions Command with Individual Session Control

   The message is terminated with a single block HMAC, as illustrated

How is this calculated?
I suspect you meant HMAC as defined in Section 3.2 of RFC 4656,
but it would be good to say this explicitly somewhere in the document
(Somewhere around Introduction? HMAC is used in several places in
the document.)

(Tim Polk) No Objection

Comment (2010-04-08 for -)
No email
send info
I support Sean's Discuss on HMAC pecification.

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection