A Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-09
Yes
(Lars Eggert)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Pasi Eronen)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
(2008-07-17)
Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2008-07-15)
Unknown
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.
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2008-07-16)
Unknown
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.
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2008-07-16)
Unknown
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...