Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07

From: Klaas Wierenga <[email-masked]>
Date: Mon, 4 Feb 2013 16:10:22 +0100

I have reviewed this document as part of the security directorate's  ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The draft defines three RTCP XR block types for reporting loss, duplication and discard summary statistics independent from the RTP application that is used, augmenting the ones in RFC3611.

The draft is well written and clear, and I have only minor comments/questions:

* 1.1 Summary Statistics Metrics

Since these are summary (as opposed to raw) statistics metrics, does that mean that the concerns wrt to confidentiality are somewhat alleviated? And if so, shouldn't that go in the security considerations? 

* 2.1 Standards language

Picture Type 

It is not clear from the text what Picture Type means. Are you saying that the 2 choices for Picture Type are respectively Key Frame and Derived Frame? If so, please make that more clear. Picture Type also seems a bit of a misnomer, but I guess Frame Type has unwanted connotations as well

* 7 Security Considerations

See my remark on 1.1

Cheers,

Klaas

---

From: Qin Wu <[email-masked]>
Date: Tue, 5 Feb 2013 09:56:55 +0800

Hi,Klass:
Thank for your valuable review, your comments will be addressed in the update.
Please see my reply below.

Regards!
-Qin
----- Original Message ----- 
From: "Klaas Wierenga" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "The IESG" <[email-masked]>
Sent: Monday, February 04, 2013 11:10 PM
Subject: secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07

[Qin]: I prefer to keep as it does since both summary and raw face the same level confidential risk without using SRTP protection. The concern wrt to confidientiality will be addressed by security section of RFC3611,i.e., using SRTP. 

* 2.1 Standards language

Picture Type 

[Qin]: Good point, I propose to change Picture Type into Frame Type although they are the same thing, in addition, I propose to change the definition of Picture Type as follows:
OLD TEXT:
"

   Picture Type

      Picture Types used in the different video algorithms are composed
      of the Key frame and Derived frames.  The Key frame is
      independently coded without prediction from other pictures and
      used as a reference frame for predicting other pictures.  Derived
      frames are predicatively coded and derived from a Key frame using
      a prediction algorithm.

"
NEW TEXT:
"
 Frame Type
 A video frame is compressed using different algorithms. 

 Frame type is used to identify different algorithms for video frames. 

 Two frame Types used in the different video algorithms are the Key 

 frame and Derived frames.  The Key frame is independently coded without

 prediction from other pictures and used as a reference frame for 

 predicting other pictures.  Derived frames are predicatively coded 

 and derived from a Key frame using a prediction algorithm.

"

See my remark on 1.1

Cheers,

Klaas=