Re: [xrblock] WGLC on draft-ietf-xrblock-rtcp-xr-synchronization-02.txt

["Huangyihong (Rachel)" <[e-mail]>]

Hi Dan,

Sorry for the late reply. Please see inline.

Best regards 
Rachel

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Romascanu, Dan (Dan)
发送时间: 2013年3月7日 20:09
收件人: Shida Schubert; xrblock
主题: Re: [xrblock] WGLC on draft-ietf-xrblock-rtcp-xr-synchronization-02.txt

Hi,

Please find below my comments: 

1. Are the Initial Synchronization Delay and the Synchronization Offset new metrics introduced by this draft? So it seems, as in section 2.1 the mention to the Initial Synchronization Delay has a reference to RFC 6051, but there is no metric definition there, while the explanation about the Synchronization Offset seems to include a self-contained definition. In this case I believe that the guidelines of using the template in RFC 6390 applies, and section 2.1 must be re-written on these lines. 

2. Section 1.4 introduces the term of 'layered video sessions' which is used for the rest of the draft, with a reference to RFC 6190. However, RFC 6190 does not include or ever mentions 'layered video sessions' but rather 'layered multicast'. If this is the same term please mention this, or explain the relation. 

[Rachel]: Good catch. How about changing to "layered encodings"?

3. In section 3.2: 

>     It is
      recommended that the beginning of multimedia session is chosen as
      the time when the receiver has joined the first RTP session of the
      multimedia session.

Should not be RECOMMENDED (capitalized)? 

[Rachel]: Right. It should be capitalized. Thanks.

4. Same comment for the two instances of 'recommended in Section 4: 

>  For multimedia session with
   multiple media types (e.g., audio and video), it is recommended to
   choose the stream with the lower bandwidth as the reference stream.
   For layered video sessions, it is recommended to use the base layer
   stream as the reference stream.

[Rachel]: Okay.

5. The Security Considerations section mentions that 

>    The new RTCP XR report blocks proposed in this document introduces no
   new security considerations beyond those described in [RFC3611].

However, the text in the Security Consideration section of RFC 3611 was refering only to voice calls carried by RTP: 

>   The VoIP Metrics Report Block provides information on the quality of
   ongoing voice calls.  Though such information might be carried in an
   application specific format in standard RTP sessions, making it
   available in a standard format here makes it more available to
   potential eavesdroppers.

A supplementary statement should mention the fact that the extended report blocks defined by this document provide information not only about outgoing voice calls but als about other RTP applications like video sessions and multimedia sessions. Making available information about this applications in a standard format is also a potential security concern. 

[Rachel]: Okay. Will add this.

Regards,

Dan


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Shida Schubert
> Sent: Wednesday, February 20, 2013 12:44 AM
> To: xrblock
> Subject: [xrblock] WGLC on draft-ietf-xrblock-rtcp-xr-synchronization-
> 02.txt
> 
> This is an announcement of a 2 weeks XRBLOCK WG last call on "Report
> Block for Synchronization Delay and Offset Metrics Reporting"
> priorto requesting publication of the document as a proposed standard.
> 
> Please send your comments, including nits, to the list by the
> 
> 8th of March (Just before the next IETF meeting in Orlando)
> 
> If you read the draft and you see no issues, concerns, or nits, please
> express the fact that you have no issue progressing the draft on the
> list as well.
> 
> The latest version can be found here:
> 
> http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-synchronization-02.txt
> 
> Regards
> 
> Shida as co-chair
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
_______________________________________________
xrblock mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/xrblock