RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting
draft-ietf-xrblock-rtcp-xr-delay-12

Nicely written document.  Just one non-blocking comment that you needn't respond to.

-- Section 3.2 --
A very minor point, but I find the double-parenthesised explanation of the Interval Metric Flag to be somewhat awkward.  I will suggest this, but if you don't want to change it that's also fine:

NEW
   This field is used to indicate whether the Delay metrics are
   Sampled, Interval or Cumulative metrics:
   
      I=10: Interval Duration - the reported value applies to the most
         recent measurement interval duration between successive metrics
         reports.

      I=11: Cumulative Duration - the reported value applies to the
         accumulation period characteristic of cumulative measurements.
 
      I=01: Sampled Value - the reported value is a sampled instantaneous
         value.
END

Thanks for addressing my comments, copied over here, for historical reasons:

In one of my previous DISCUSS-DISCUSS on xr-block, we settle on:

      - RFC 6390 template is required for new perf metric definition

      - RFC 6390 template is a nice-to-have when we refer to an existing
      perf metric

      Nice-to-have because the performance metric reference doesn't
      always include all the required information about: measurement
      points, measurement timing, use and applications, reporting model,
      etc... but focus only on the "Method of Measurement or
      Calculation"     

It might not be fair to change the requirements on this document, while it left the WG some time ago. So I'm ready to let go without the RFC6390 template (http://tools.ietf.org/html/rfc6390#section-5.4.4)
So I'm not opposed to the publication of this document for THAT reason. Note that I will be stricter with future documents.

However, back to this document. You should do a better job of documenting what is required, both from an implementer point of view, and the performance metrics semantic, for someone who might want to(re)- use the metric.
Feel free to discuss with me if I can be of any help

For example: the measurement period is mentioned multiple times in the metric definitions

 Mean Network Round Trip Delay: 32 bits

      The Mean Network Round Trip Delay is the mean value of the RTP-to-
      RTP interface round trip delay over the measurement period,
      expressed in units of 1/65536 seconds.  

However, you don't mention where to find it.
I guess it relates to the measurement interval mentioned in

   This metric block
   relies on the measurement interval in the Measurement Information
   block indicating the span of the report and SHOULD be sent in the
   same compound RTCP packet as the measurement information block. 

Assuming that the readers understand that the two different names are related, it doesn't tell where to find this information. Is this in http://datatracker.ietf.org/doc/rfc6776/ ?

For example,

   Min Network Round Trip Delay: 32 bits

      The Min Network Round Trip Delay is the minimum value of the RTP-
      to-RTP interface round trip delay over the measurement period,
      expressed in units of 1/65536 seconds.  This value is typically
      determined using RTCP SR/RR.  It also can be determined using RTCP
      Receiver Reference Time Report Block and DLRR Report Block.

The last two sentences. Why not be a little bit more explicit, telling exactly which fields need to be taken into consideration from RTCP SR/SR and from DLRR report block.

- 3.2: Is the reference to 3611, section 4.1 correct as a
definition for SSRC?

- Not a comment on this draft, but rfc 3611 says that XR
packets should not be encrypted. Has anyone looked to see if
the information leaked by reporting like this could expose
information about encrypted e.g. VoIP traffic?  For example,
the SSRC will be sent in this report in clear, so one might
wonder if that could help someone attack elsewhere. Since
the xrblock WG are doing a bunch of these, I guess it
migth be worth some thought to see if there are any bad
security effects with all of that.