Skip to main content

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)

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...