A Two-Way Active Measurement Protocol (TWAMP)
RFC 5357
Note: This ballot was opened for revision 09 and is now closed.
(Lars Eggert) (was Discuss, Yes) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Pasi Eronen) No Objection
(Russ Housley) No Objection
Comment (2008-07-16 for -)
No email
send info
send info
I find the introduction to this document quite confusing. I would me much happier with an introduction that tells the reader about the shortcomings of the current ICMP Echo-based solution and how the addition of a timestamp by the reflector is an improvement. Please define "MBZ". Suresh Krishnan suggested the following: > > The bits marked MBZ MUST be set to zero by senders and MUST be > ignored by receivers. Suresh Krishnan suggested that Section 3.8 set the number of sessions field to 0 since there are no session description records that follow.
(Cullen Jennings) No Objection
(Chris Newman) (was Discuss) No Objection
Comment (2008-07-17)
No email
send info
send info
The use of UTF-8 for KeyID is sufficiently narrow that it's unlikely to create interoperability issues, but a reference to RFC 5198 would reduce the chances of problem. Without some canoncialization, it's possible to have a KeyID most people can't type but it's unlikely people will actually do that in practice.
(Jon Peterson) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
Comment (2008-07-16)
No email
send info
send info
Section 1.2, Logical Model, implies that Session-Sender's definition is unchanged from that in OWAMP. Doesn't the Session-Sender need to be the entity that "is capable of returning the results of a test session" since the Server no longer fills that role? If that is true, I believe Session-Sender should be added to the list with its expanded role. It strikes me as a little odd that the first block of a message is encrypted in "authenticated only mode". It would be helpful if the security considerations shed some light on this architectural decision. (I realize that this is a carryover from 4656, but I didn't find a rationale there either.) Upon review, the use of CBC with an IV of zero seems to be secure in the context of this protocol. However, generation of an IV in addition to the key material doesn't seem to be an insurmountable problem. I am curious why the designers of OWAMP chose this path...
(Dan Romascanu) No Objection
Magnus Westerlund No Objection
Comment (2008-07-15 for -)
No email
send info
send info
Section 4.2.1: (with the implication that the later two modes will not fit in a single ATM cell) Is this comment at all relevant as there will be an IP and UDP header on the packet also, making the smallest packet size become 28+41? Or is the intention to allow the format to be used with other encapsulations then IP/UDP? Then I would expect a clearer description of this fact and recommendation on what is necessary for that usage.