This document specifies 4 new IPFIX IEs for on path delay measurement results reporting.
I have read the latest version of this draft and I think the draft is on the right track. Here
are a few comments I would like to ask authors to consider:

1. Section 3.2.5 T0 and T1 definitions
"
   T0:  T time, the start of a measurement interval (format "date/time"
      as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
      in Section 3 of [RFC6991]).  The UTC Time Zone is required by
      Section 6.1 of [RFC2330].  When T0 is "all-zeros", a start time is
      unspecified and Tf is to be interpreted as the duration of the
      measurement interval.  The start time is controlled through other
      means.

   Tf:  A time, the end of a measurement interval (format "date/time" as
      specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
      Section 3 of [RFC6991]).  The UTC Time Zone is required by
      Section 6.1 of [RFC2330].  When T0 is "all-zeros", an ending time
      and date is ignored and Tf is interpreted as the duration of the
      measurement interval.
"
Both T0 definition and T1 definition emphasize when T0 is "all-zeros", Tf is 
interpreted as the duation of the measurement interval, I think it is not
necessary to repeat this statement, suggest to remove such duplication in both defintions.

2. Measurement method in section 3.4.2.1, Section 3.4.2.2, section 3.4.2.3, section 3.4.2.4
Since section 3.4.2.3 provide calculation formula for OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max,
for consistency, I think section 3.4.2.1, section 3.4.3.2, section 3.4.2.4
should also provide calculation formula for mean, min and sum related metric.

3. Measurement method for section 3.4.2.4
Section 3.4.2.4 said:
"
However in this case FiniteDelay or MaxDelay MAY be used.
"
Can you clarify in which circumstance the finitedelay or maxdelay will be used?
Also I am wondering whether you use MinDelay or MeanDelay to calculating
statistics, see section 4.2.5 and section 4.3.5 of RFC6049 for calculating formula.


4. Table 2
"
+-----------+-----------+------+-------------+-------------+-----------+
| ingress   | egress    | Node | destination | srhActive   |   Path    |
| Interface | Interface |      | IPv6Address | SegmentIPv6 |   Delay   |
+-----------+-----------+------+-------------+-------------+-----------+
|    271    |    276    |  R1  | 2001:db8::2 | 2001:db8::4 |    0 us   |
+-----------+-----------+------+-------------+-------------+-----------+
|    301    |    312    |  R2  | 2001:db8::3 | 2001:db8::4 |   22 us   |
+-----------+-----------+------+-------------+-------------+-----------+
|    22     |     27    |  R3  | 2001:db8::4 | 2001:db8::4 |   42 us   |
+-----------+-----------+------+-------------+-------------+-----------+
|    852    |    854    |  R4  | 2001:db8::4 | 2001:db8::4 |  122 us   |
+-----------+-----------+------+-------------+-------------+-----------+
           Table 2: Example table of measured delay. Ascending by delay.
"
Consider the example depicted in figure 1, I am wondering whether
the destinationIPv6 addresses for both Node R3 and Node R4 should
be the same, i.e., 2001::db8::4, can you clarify this?


5. Section 7.3
Can you clarify why Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds
while Unsigned32 has been choosen as type for IPFIX Information Elements?
why not choose unsigned64 or unsigned32 for all new defined IPFIX IEs?

6. Section 3.1.2
The abbreviation of Observation point (OP) has been repeated multiple times,
also observation point is defined in RFC7011, I don't see RFC7011 defines
abbreviation for Observation point, therefore I suggest to remove such abbreviation as well.
Sometime use OP introducing confusing, e.g., quoted the following text
in section 3.2.1
"  With the OP [RFC7011] typically located between the hosts
   participating in the IP Flow, the one-way delay metric requires one
   individual measurement between the OP and sourcing host
"
For the first reader, he will not understand what "OP" is and also there is
no OP abbreviation defined in RFC7011.

7. Aggregated On-Path Delay Examples in Appendix
Can I use the same Data Set encoding to carry both pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds?
Or you think I should use two different Data Set encoding for pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds respectively?