BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)
draft-hunt-avt-rtcpxnq-01

I made the following comments during IETF Last. Although I received an answer from one of the editors, I do not believe that my comments were addressed. Without being show-stoppers I think that the first two issues deserve consideration if there is an opportunity for further edits. 

1.

  'This document has
   been produced to describe the report block in sufficient detail to
   register the block type with IANA, rather than with the intention of
   standardising the report block for use outside BT's network.' 

Is this a recommendation not to use this report block outside a private network? Is the scope of the document limited to providing a specification in order to fill in the Specification Required policy for requesting an RTCP XR block type as per 3611 - if this is the case it should be made clear. 

2. 

  'The metric vrange is the difference between the shortest and longest
   network packet delays seen over the duration of the connection to
   date.  The metric vrange is a positive quantity or (unusually) zero.

   The metric vmaxdiff is found as follows.  For each RTCP measurement
   cycle, find the difference between the shortest and longest network
   packet delays within that measurement cycle.  These differences are
   all positive quantities or (unusually) zero.  Take the set of these
   differences and find the maximum, which is vmaxdiff.  The metric
   vmaxdiff is also a positive quantity or (unusually) zero.' 

In order for the metrics to be expressed as positive numbers, should not the differences be defined as between the longest and the shortest network packet delays, and not the other way? 

The authors answered here that 

'Re your comment (2), I don't think that the order of X and Y in the English phrase "difference between X and Y" indicates unambiguously whether the difference X - Y or the difference Y - X is meant. Hence I included the statement that the resulting quantity is positive, and I believe that this is sufficient clarification. I wouldn't change this unless you feel strongly about it.' 

I am a little bit surprised by the argumentation but I would not argue with a native English speaker on English syntax issues. I certainly do not feel dtrongly on this. but yet, if there is a simple edit to make the text more clear, I would rather make it. 

3.  IANA considerations - I think that the Internet Draft should have asked IANA to allocate the first free Block Type number and recommend that this number be 8, as one cannot guarantee that 8 was not allocated until the time the RFC is approved. 

The author answered: 

'Re your comment (3), I agree, for the ideal world. However our problem is that we used block type 8 in specification examples and we already have suppliers' implementations using 8. It would be a major pain for us if we didn't get 8, and it was suggested that we should make this explicit in the draft. Fortunately TI were aware of our work and asked IANA to bypass 8, and to allocate 9 to TI's PIQUA application. Hence 8 is kind-of reserved for us (currently marked "Unassigned" on the IANA web page) and I believe this will remain true until the draft becomes an RFC, assuming no untoward delays.'

OK by now, but probably something to be kept in mind for the future by the AVT chairs.

  Some metrics (vrange is an example) are described as "positive
  quantity or (unusually) zero", with no description of why the
  unusual zero value might arise.
  
  The phrase "an over-range value" is used in many places, but the
  meaning is unclear.