Skip to main content

A Two-Way Active Measurement Protocol (TWAMP)
RFC 5357

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 (was Discuss, Yes) Yes

(Chris Newman; former steering group member) (was Discuss) No Objection

No Objection (2008-07-17)
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 steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (2008-07-15)
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 steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2008-07-16)
  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 steering group member) (was No Record, Discuss) No Objection

No Objection (2008-07-16)
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...