Subject: [secdir] SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12

From: Matthew Lepinski <[email-masked]>
Date: Wed, 17 Apr 2013 16:22:14 -0400

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.

Summary: In my opinion this document is acceptable. I have no concerns with
this document.

This document describes a new RTCP block for use in the RTCP eXtended
Reporting (XR) framework. The block specified in this protocol is a
companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard.
Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the number of
packets discarded without being used (played out), this current draft
allows a receiver to provide additional data regarding the pattern of
discarded packets. That is, how many of the discarded packets arrived
during intervals of high discard rate (i.e., intervals of poor quality due
to many discards).

The document authors claim that this draft introduces no new security
considerations beyond those described in RFC 3611 (RTCP eXtended Reports).
I agree with this assessment.

I did have one minor question about Section 3.2. I admit that I am not an
RTCP expert, but I was confused by the description of the Threshold value.
The document says that the Threshold is calculated in the same way Gmin is
calculated in 3611. However, in 3611 it appears that Gmin is a value
configured by the receiver (Recommended to be 16, but can be set to any
non-zero value the receiver desires.) Am I correct in assuming that
Threshold is also a configured value sent by the receiver?

Finally, do you expect implementations to use both the VoIP Metrics block
and the Burst/Gap Discard block together (for the same RTP session)? If so,
is it important that the Threshold in the Burst/Gap Discard block be set to
the same value as the Gmin value in the VoIP Metrics block? (If there are
any problems that would arise if the two parameters were set to different
values, those should be mentioned. If there are no anticipated issues with
setting the values independently, then that's fine there is no need to say
anything more than is currently in the document.)

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Apr 2013 03:26:47 +0000

Dear all,
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.

It is technically ready, but a few editorial suggestions are below.

Typo, second-last paragraph of Section 1, last sentence:
  s/doxument/document/

Editorial suggestion: introduce the abbreviations P2P and P2MP in their respective bullets at the beginning of Section 1.1. According to the RFC Editor's list of abbreviations at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt,
these are not considered well-known, therefore need to be spelled out on first use. Note the capitalization, per the RFC Editor's list.

In case 3. of Section 1.1, delete "that" after "operator command" in the first line to make it consistent with the other two cases.

Section 1.2 first paragraph last sentence: the subject of the sentence is the singular "Requirement", hence s/are/is/ in the final line.

The authors can consider whether they need to spell out LSP and LSR at the start of Section 1.3. Again, the RFC Editor does not consider these to be "well-known" abbreviations.

Second paragraph below Figure 1: The last sentence begins: "Coordination of the switchover ..." I assume the intention here is to indicate that in this case operation is not so simple as the first sentence indicates.
That should perhaps be signalled by beginning the sentence with:
"However, coordination of the switchover ..."

Sentence before Figure 7: s/complimentary/complementary/

Spell out e2e in the second paragraph below Figure 8, since it is used once only.

Thank you,
Tina

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Apr 2013 06:13:47 +0000

Thank Mattew for your valuable review.
Please see my reply inline below.

Regards!
-Qin
发件人: Matthew Lepinski [mailto:[email-masked]]
发送时间: 2013年4月18日 4:22
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12

Summary: In my opinion this document is acceptable. I have no concerns with this document.

This document describes a new RTCP block for use in the RTCP eXtended Reporting (XR) framework. The block specified in this protocol is a companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the number of packets discarded without being used (played out), this current draft allows a receiver to provide additional data regarding the pattern of discarded packets. That is, how many of the discarded packets arrived during intervals of high discard rate (i.e., intervals of poor quality due to many discards).

The document authors claim that this draft introduces no new security considerations beyond those described in RFC 3611 (RTCP eXtended Reports). I agree with this assessment.

[Qin]: Thanks.

I did have one minor question about Section 3.2. I admit that I am not an RTCP expert, but I was confused by the description of the Threshold value. The document says that the Threshold is calculated in the same way Gmin is calculated in 3611. However, in 3611 it appears that Gmin is a value configured by the receiver (Recommended to be 16, but can be set to any non-zero value the receiver desires.) Am I correct in assuming that Threshold is also a configured value sent by the receiver?

[Qin]: The text you are referring to (i.e., Threshold is calculated in the same way Gmin is calculated in 3611.) was added corresponding to PM-DIR review. You are right, Gmin is configuration parameter sent by the receiver. Gmin can be other value than 16, see RFC3611, section 4.7.1
“
If the packet spacing is 10 ms and the Gmin value is the recommended
   value of 16, the burst duration is 120 ms, the burst density 0.33,
   the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.

”
Maybe the word “calculated” is a little misleading and can be rephrased as “set”, i.e.,
The threshold is set in the same way Gmin is calculated in 3611.

Finally, do you expect implementations to use both the VoIP Metrics block and the Burst/Gap Discard block together (for the same RTP session)? If so, is it important that the Threshold in the Burst/Gap Discard block be set to the same value as the Gmin value in the VoIP Metrics block? (If there are any problems that would arise if the two parameters were set to different values, those should be mentioned. If there are no anticipated issues with setting the values independently, then that's fine there is no need to say anything more than is currently in the document.)

[Qin]: The threshold in the Burst gap Discard block and VOIP Metrics Block should be set to the same value if both blocks report the same stream. The threshold in the Burst gap Discard block and VOIP Metrics Block can be set to different values if burst gap discard block and VOIP metrics block report the different stream, which is identified by different SSRC.
If burst gap block and VOIP metrics block can report the same stream, I think either we use Burst Gap block or we use VOIP metrics block, usually we will not use both together to report the same stream.
So I think it is safe for keeping what it is currently described in the document as it is.

---

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 18 Apr 2013 12:47:46 +0300

Tina, hi

Thank you for your review, and thank you for the link to the official
acronym list.

I will incorporate your suggested fixes into the new version of the
document that will be uploaded shortly.

BR,
yaacov

On Thu, Apr 18, 2013 at 6:26 AM, Tina TSOU <[email-masked]>wrote:

>  Dear all,****
>
> 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
> like any other last call comments.****
>
> ** **
>
> It is technically ready, but a few editorial suggestions are below.****
>
> ** **
>
> Typo, second-last paragraph of Section 1, last sentence:****
>
>   s/doxument/document/****
>
> ** **
>
> Editorial suggestion: introduce the abbreviations P2P and P2MP in their
> respective bullets at the beginning of Section 1.1. According to the RFC
> Editor's list of abbreviations at
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt,****
>
> these are not considered well-known, therefore need to be spelled out on
> first use. Note the capitalization, per the RFC Editor's list.****
>
> ** **
>
> In case 3. of Section 1.1, delete "that" after "operator command" in the
> first line to make it consistent with the other two cases.****
>
> ** **
>
> Section 1.2 first paragraph last sentence: the subject of the sentence is
> the singular "Requirement", hence s/are/is/ in the final line.****
>
> ** **
>
> The authors can consider whether they need to spell out LSP and LSR at the
> start of Section 1.3. Again, the RFC Editor does not consider these to be
> "well-known" abbreviations.****
>
> ** **
>
> Second paragraph below Figure 1: The last sentence begins: "Coordination
> of the switchover ..." I assume the intention here is to indicate that in
> this case operation is not so simple as the first sentence indicates. ****
>
> That should perhaps be signalled by beginning the sentence with: ****
>
> "However, coordination of the switchover ..."****
>
> ** **
>
> Sentence before Figure 7: s/complimentary/complementary/****
>
> ** **
>
> Spell out e2e in the second paragraph below Figure 8, since it is used
> once only.****
>
> ** **
>
> ** **
>
> Thank you,****
>
> Tina****
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Matthew Lepinski <[email-masked]>
Date: Thu, 18 Apr 2013 13:24:42 -0400

Thank you for the prompt response. Your explanation makes sense to me.

On Thu, Apr 18, 2013 at 2:13 AM, Qin Wu <[email-masked]> wrote:

>  Thank Mattew for your valuable review. ****
>
> Please see my reply inline below.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* Matthew Lepinski [mailto:[email-masked]]
> *发送时间:* 2013年4月18日 4:22
> *收件人:* [email-masked]; [email-masked]
> *抄送:* [email-masked]
> *主题:* SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12****
>
> ** **
>
> Summary: In my opinion this document is acceptable. I have no concerns
> with this document.****
>
> ** **
>
> to many discards).****
> I agree with this assessment.****
>
> ** **
>
> [Qin]: Thanks.****
>
> ** **
>
> Threshold is also a configured value sent by the receiver? ****
>
> ** **
>
> [Qin]: The text you are referring to (i.e., Threshold is calculated in the
> same way Gmin is calculated in 3611.) was added corresponding to PM-DIR
> review. You are right, Gmin is configuration parameter sent by the
> receiver. Gmin can be other value than 16, see RFC3611, section 4.7.1****
>
> “****
>
> If the packet spacing is 10 ms and the Gmin value is the recommended****
>
>    value of 16, the burst duration is 120 ms, the burst density 0.33,****
>
>    the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.***
> *
>
> ** **
>
> ”****
>
> Maybe the word “calculated” is a little misleading and can be rephrased as
> “set”, i.e.,****
>
> The threshold is set in the same way Gmin is calculated in 3611.****
>
> ** **
>
> anything more than is currently in the document.)****
>
> ** **
>
> [Qin]: The threshold in the Burst gap Discard block and VOIP Metrics Block
> should be set to the same value if both blocks report the same stream. The
> threshold in the Burst gap Discard block and VOIP Metrics Block can be set
> to different values if burst gap discard block and VOIP metrics block
> report the different stream, which is identified by different SSRC.****
>
> If burst gap block and VOIP metrics block can report the same stream, I
> think either we use Burst Gap block or we use VOIP metrics block, usually
> we will not use both together to report the same stream. ****
>
> So I think it is safe for keeping what it is currently described in the
> document as it is.****
>
> ** **
>
> ** **
>
> ** **
>