Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)
RFC 5938
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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 applicability. 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.
(Alexey Melnikov; former steering group member) No Objection
3.2. Start-N-Sessions Command with Individual Session Control The message is terminated with a single block HMAC, as illustrated above. 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.)
(David Harrington; former steering group member) No Objection
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
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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
stopped).
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.
(Peter Saint-Andre; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I support Sean's Discuss on HMAC pecification.