Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-type-p-monitor-03

Just a couple of nits:

In Section 2.2.1., please put a reference to rfc5357 (?) to show where the test packet formats came from and to indicate where the fields are described.

Figure 4 doesn't show the S-DSCP-ECN field in it.

Just a few mostly editorial comments:

- Abstract: Did you mean OPTIONAL to be capitalized in the abstract? I'm not sure what the purpose of a 2119 keyword would be there.

- 1, first paragraph:
There are lots of missing articles ("the") in the first paragraph.

-1, 2nd paragraph:
There's no need to say it's OPTIONAL more than once.

- 2.1, 1st paragraph:
"DSCP and ECN monitoring flag" and "Mode" each need a leading "the".

- 2.2.1:
The MUST in the first paragraph is not really needed. The Session-Reflector either supports the extension and does these things, or does not support the extension and does not do these things.

- First bullet in list at end of 2.2.1:
s/extracts/extract

As mentioned by Al Morton, part of his OPS DIR review:

Summary: Almost ready, comments and editorial suggestions follow.

The draft header should indicate that this draft updates RFC 5357.

Section 2.2.1

Figure 1 has a number of canonical references that should 
be cited to ensure IPv4 and IPv6 applicability, including 
RFC 2474, RFC 3168, and other relevant updates (of which 
there are many).

<later>
   o  if the negotiated/provisioned DSCP value is not known (e.g.  TWAMP
      Light), the choice of the DSCP is implementation specific.  For
      instance, Session-Reflector MAY copy the DSCP value from the
      received test packet and set it as DSCP in a reflected packet.
Question:
What about the ECN value?   From 3168:
      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE
It makes little sense to copy a "11" == CE into the reflected packet,
and it may affect the measured performance if "11" were copied.
The draft needs more guidance here (there is a general problem
when the negotiated values are "not known"; this does not apply 
to the Standards Track TWAMP protocol or its extensions).

-=-=-=-=-=-=-=-=-=-=-=-=-

Editorial comments/suggestions:

OLD
2.2.  TWAMP-Test Extension

   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the format of its test packet format both in
   unauthenticated, authenticated and encrypted modes. 
Suggest:
   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the test packet format in all the original
   (unauthenticated, authenticated and encrypted) modes. 

2.2.1

OLD
   o  the first six bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the following two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.
Suggest:
   o  the six (least-significant) bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.

because RFC 3168 defines:
         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |          DS FIELD, DSCP           | ECN FIELD |
      +-----+-----+-----+-----+-----+-----+-----+-----+

        DSCP: differentiated services codepoint
        ECN:  Explicit Congestion Notification

      Figure 2: The Differentiated Services and ECN Fields in IP.
-=-=-=-=-=-=-=-

OLD
    0     1     2     3     4     5     6     7     8
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               S-DSCP              |   S-ECN   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Sender DSCP and ECN field format

Suggest:
The extra "+" within bit positions are distracting,
and don't conform to the conventions of these diagrams.
Also, there's no "8" when numbering from 0.

Some attempt should be made to put Figure 3 on a single page in the 
final version. There's one line taken up by "+" that is unnecessary
in the modified field:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sender TTL  |  S-DSCP-ECN   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                             |
 >> +                                                             + <<
    |                       MBZ (14 octets)                       |
    |                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since rfc5357 has more discussion on the differences between unauthenticated, authenticated, and encrypted modes, it would be helpful to have a pointer to that specific point in the Security Considerations section.