RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting
draft-ietf-xrblock-rtcp-xr-pdv-08

Thanks for addressing my Discuss and paying attention to my Comments

Just one non-blocking comment on the abstract:
The abstract should be readable on its own by someone who doesn't know what RFC XYZ is about and sees only the title and abstract.  Someone who doesn't know what RTP and RTCP are won't get any clue from the abstract.  Will you consider this, so people will immediately see what the document refers to?:

OLD
   This document defines an RTCP XR Report Block that allows the
   reporting of Packet Delay Variation metrics for a range of RTP
   applications.
NEW
   This document defines a Real-Time Control Protocol (RTCP)
   Extended Report (XR) block that allows the reporting of Packet
   Delay Variation metrics for a range of Real-time Transport
   Protocol (RTP) applications.

---
Also, I will note that the shepherd writeup is incorrect:

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>
> N/A

Section 5.4 creates a new registry with Specification Required policy, which requires the appointment of a designated expert.  I presume the ADs have or will get the input they need to appoint one, but I wanted to point out the need, since the shepherd writeup didn't.

I had a discussion with Dan Romascanu, and we settled 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"

So basically, at this point, I will clear my DISCUSS-DISCUSS

Somehow, I've been trying to solve a growing problem, and potentially bigger problem:

Where does the list of performance metric definitions come from at
the IETF? We have multiple sources: 
- IPPM for IP performance metrics. 
- RTCP for RTP performance metrics:
- PMOL: Performance Metrics at Other Layers, with
  RFC 6076 on Basic Telephony SIP End-to-End Performance Metrics
- IPFIX will one day or the other exports performance metrics.
  I see for example
  http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-ipfix-03.
  It's again a redefinition, and it should not be!

My concerns are that we start to define performance metrics in different parts
of the IETF, without consistency. 
And even finding the performance metrics specified in the IETF is not an easy task.

I've convinced that the community will have solve this problem, and I will propose a meeting during the next IETF to try to come up with a solution. This meeting should include the PMOL directorate, the XRBLOCK chairs, and the IPPM chairs.
If someone not in the mentioned list wants to participate, let me know privately.

Regards, Benoit.

I've cleared my comment.

Documents like this would benefit from a worked example showing a set of RTP packets as seen by the element doing the metric calculation, demonstrating where the inputs to the calculation come from. Please consider such a section for future documents of this type.

Should the Y.1540 reference be updated to the currently in force version (Mar2011)?

1) s1.2: Is this a "MUST":

r/This draft defines a new Extended Report block that
   must be used in accordance with [RFC3550] and [RFC3611].
/This draft defines a new Extended Report block
   for use with [RFC3550] and [RFC3611].

2) s3.2, Packet Delay Variation Metric Type: Trying to figure out whether there some other way to interpret an enumerated ;)  Maybe just replace should be/is:

r/Packet Delay Variation Metric Type is of type enumerated and
      should be interpreted as Integer.
/Packet Delay Variation Metric Type is of type enumerated and
      is interpreted as Integer.

3) s3.2: Reserved: Curious why there's a SHOULD where almost every other time I can remember it's a MUST for setting reserved bits to zero:

 In the absence of
 such a definition, the bits in this field SHOULD be set to zero
 and MUST be ignored by the receiver.

4) s3.2: Positive PDV Threshold/Peak (and others): Is the S11:4 format documented somewhere?

Two nitty-nits:-)

- maybe expand PDV and MAPDV on 1st use in draft.
- maybe add a reference for "2-point PDV"