Subject: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08

From: Claudio Allocchio <[email-masked]>
Date: Thu, 14 Feb 2013 15:20:29 +0100 (CET)

Hello all,

I have been selected as the Applications Area Directorate reviewer for 
this draft; for background on appsdir, please see 
​
  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate

Please resolve these comments along with any other Last Call comments you 
may receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-ietf-xrblock-rtcp-xr-summary-stat-08
Title:  RTP Control Protocol (RTCP) Extended Report (XR) Blocks for
         Summary Statistics Metrics Reporting
Reviewer: Claudio Allocchio
Review Date: Feb 13th 2013
IETF Last Call Date: n/a
IESG Telechat Date: Feb 21st 2013

Summary:

There is one recurring Major Issue which I think requires a better wording 
to avoid the risk of different incompatible implementations. After this is 
fixed, the work is ready for publication.

Major Issues:

3.1.2

Burst Loss Rate: 16 bits

the whole paragraph is the "verbal description of a formula", which 
however is not present after the paragraph itself... worst... the formula
which is presented

    Packets Loss in Bursts / Total Packets expected in Bursts

is just a part of the missing complete formula. Please add the complete 
formula after the paragraph, or people will have to read it many times, 
and invent themselves the formula: math books can be written without a 
single "word" and everyone understand them the same way. The risk is here 
that many will write a different formula after reading the text. I also 
had a need for multiple reading of the "expressed as a fixed point number 
with the binary point at the left edge of the field"... maybe you can 
rewrite this better, too.

Gap Loss Rate: 16 bits

same problem as above: please add the explicit formula.

3.2.2

Burst Discard Rate: 16 bits

same problem as in 3.1.2 above: please add the explicit formula.

Gap Discard Rate: 16 bits

same as above: please add the explicit formula.

Minor Issues:

2.1 Terminology

the sentence "A video frame is compressed using different algorithms" 
gives an absolute affirmation wich is not 100% true. Not all applications 
compress video frames, there are a few which send uncompressed video, thus 
all frames are "Key Frames" according to this definition and there are no 
"Derived Frames". In other cases frame compression is applied to color 
encoding, and not to image content itself, etc.

I just suggest a more relaxed "In many cases, a video frame is compressed 
using different algotithms", and later, the addition of ..."Derived frames 
are predicatively coded and derived from a Key frame using a prediction 
algorithm. If there is no video image compression, all frames are Key 
Frames".

3.1.2

Reserved: 6 bits

if the sender MUST put all zeroes, because the field it not yet in use, 
the receiver MUST ignore its content. Why there is a SHOULD? what the 
recipient could do with an all zeroes field of no use? Is there someting I 
do not get correctly? if so, then we should explain this ... I might be an 
implementer and do it wrong.

3.2.2

Reserved: 6 bits

same as above for 3.1.2

4.1.2.

Reserved: 7 bits

same as above for 3.1.2

Nits:

4.1.2

full_lost_frames  vs  full_lost-frames later in the text... maybe other 
variants... choose 1, and use it all the time.

Authors' Addresses

in RFCs all "authors" are just "editors" when the work is coming out of a 
WG. :-)

why adding "(editor)" aside just one of them?

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Feb 2013 09:55:15 -0500

Thanks for the appsdir review, Claudio.

> the whole paragraph is the "verbal description of a formula", which however
> is not present after the paragraph itself... worst... the formula
> which is presented
...
> multiple reading of the "expressed as a fixed point number with the binary
> point at the left edge of the field"... maybe you can rewrite this better,

Yes, I picked both of these up in my DISCUSS position the other day as
well, and Glen has agreed to change the text and the formula.

> why adding "(editor)" aside just one of them?

The usual reason for this is to note the one or ones, in particular,
who "held the pen".  Sometimes it's someone who took over after other
authors were re-assigned or changed jobs, and that sort of thing.

Barry

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 14 Feb 2013 16:07:42 +0100 (CET)

> well, and Glen has agreed to change the text and the formula.

good to know that's it not just me: I was suspecting "I'm getting old, I 
need to read more than twice to understand it..." :-)

> authors were re-assigned or changed jobs, and that sort of thing.

its really really an insignificant "curiosity" ;-)

---

From: Qin Wu <[email-masked]>
Date: Sat, 16 Feb 2013 14:29:57 +0800

Hi,Claudio:
Thank for your valuable review. We will fix the issues you raised below in the update.

Regards!
-Qin
----- Original Message ----- 
From: "Claudio Allocchio" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 14, 2013 10:20 PM
Subject: APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08

> rewrite this better, too.

[Qin]: Okay, Barry raised this issue as well. We will fix this as he proposed.
> same problem as above: please add the explicit formula.

[Qin]: Okay.
> same problem as in 3.1.2 above: please add the explicit formula.

[Qin]: Okay.

> same as above: please add the explicit formula.

[Qin]: Okay.

> algorithm. If there is no video image compression, all frames are Key 

[Qin]: You are right and good suggestion. Thanks.

> implementer and do it wrong.

[Qin]: You are right, we should use "MUST" instead.
> same as above for 3.1.2

[Qin]: Okay, will fix this.
> same as above for 3.1.2

[Qin]: Okay, will fix this.

> variants... choose 1, and use it all the time.

[Qin]: Okay, will fix this.