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.

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.

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

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.