Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

From: Robert Sparks <[email-masked]>
Date: Thu, 01 Mar 2012 16:27:13 -0600

Summary: There are some clarifications needed (and some questions to 
discuss) before forwarding this to IETF LC.

1) Section 3, paragraph 3, says a receiver MUST follow the rules for 
NACK suppression on receipt of a third partly loss report. Section 4 
says receivers MAY ignore third party lost reports, and then confusingly 
says the SHOULD not ignore them. The security considerations section 
says that receivers would be "well advised to ignore" (effectively 
SHOULD ignore) third party reports unless they are authenticated. This 
needs to be reconciled.

Are you trying to say the following?

    *) MUST follow the suppression rules if packets are authenticated
    *) SHOULD NOT follow the suppression rules if the packets are not 
authenticated

Or something else? Either way, please make the document internally 
consistent.

2) Why aren't RFC3711 and RFC5124 normative references? They're the only 
offered tools for authenticating these messages in the document. Even if 
other mechanisms might exist, there needs to be discussion somewhere of 
what's required of this authentication, and the security consideration 
sections of those documents would suffice.

3) The first part of the IANA considerations section is not clear. Is 
this trying to create a new registry with two initial values, or add two 
values to an existing registry. If it's creating a new one, please 
provide a registry name, and suggest where it should appear.

4) The security considerations section speaks about attacks based on 
spurious reports, but doesn't really discuss more directed attacks. In 
particular, if a receiver accepts unauthenticated feedback suppression 
messages, an attacker could cause packetloss disrupting an important 
part of a session, preemptively sending feedback suppression. An 
attacker that is also a receiver has enough information to suppress 
_all_ feedback from any other listeners that don't unauthenticated 
packets. Please make it clearer that these risks exist.

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

Editorial suggestions:

Please expand acronyms on first use (There are a _lot_ of acronyms, many 
of which need references to where they are defined. Consider adding a 
glossary so you can get that out of the way without interrupting the 
flow of the text).

The protocol definition part of this document (section 4) is a bit of a 
puzzle for a new reader. It would help to guide the reader through the 
definition more directly. Here's a suggested modification - feel free to 
ignore it:

Before section 4.1 say "The following two sections each define a third 
party loss report message. Both messages are feedback messages as 
defined in section 6.1 of RFC4585, and use the header format defined 
there. Each section defines how to populate the PT, FMT, length, SSRC or 
packet sender, SSRC of media source, and FCI fields in that header."

That will make it more obvious to the reader that they need to go look 
at the referenced section in 4585 right away, and makes it possible to 
simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that 
it is defining the TLLEI, etc.

Whether you choose to act on this suggestion or not, please change the 
TBDs to TBD1 and TBD2, and say "length field in the" instead of "length 
of" when talking about setting the length field in each message.

Nits sent directly to editors.

---

From: Qin Wu <[email-masked]>
Date: Fri, 02 Mar 2012 12:52:59 +0800

Hi, Robert:
Thank for your valuable review, please see my replies inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Gonzalo Camarillo" <[email-masked]>
Sent: Friday, March 02, 2012 6:27 AM
Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

> Or something else? Either way, please make the document internally 

[Qin]: The reason to use "MUST" is it was suggested by the reviewer since RFC4585 that uses "MUST" 
in the context of client feedback suppression. But I agree this description does not clarify in what 
circumstance to apply MUST. To be consistent with what we described in the security section, 
I agree with your suggestion to the security section, that is to say the suppression rule is only 
applied when the packet are integrity protected and authenticated. I can put some text to make this clear.

> sections of those documents would suffice.

[Qin] Agree, for discussion on where the authentication is required, 

I like to follow your suggestion, please see above clarification. Also

 I will move RFC3711 and RFC5124 to normative references.

Does this address your comment?

> provide a registry name, and suggest where it should appear.

[Qin]: I think it is latter. To make it clear, I propose the following change:

OLD Text:

"

   For use with "nack" [RFC4585], a joint sub-registry has been set up

   that registers the following two values:

  The value registration for the attribute value "nack":

"
New Text:

"

For use with "nack" [RFC4585], this document instructs IANA to add two values in

"ack" and "nack" Attribute Values registry:

The value registration for the attribute value "nack":

"

> packets. Please make it clearer that these risks exist.

[Qin]: Okay. Based on your above suggestion, I like to propose the following change to the section 7,3rd paragraph:

OLD text:

"

Sending the spurious Third Party Loss Report (e.g., the Third Party

   Loss Report with the wrong sequence number of lost packet) that

   causes missing RTP packets to not be repaired in a timely fashion.

"

New Text:

"

Sending the spurious Third Party Loss Report packet (e.g., the Third Party

   Loss Report with the wrong sequence number of lost packet) that

   causes missing RTP packets to not be repaired in a timely fashion. 

If a receiver accepts such unauthenticated packet, 

an attacker could cause packet loss disrupting an important 
part of a session, preemptively sending feedback suppression. An 
attacker that is also a receiver has enough information to suppress 
all the feedbacks from any other listeners that don't accept unauthenticated 
packets.

"

Does this address your comment?

> suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".

> glossary so you can get that out of the way without interrupting the 

[Qin]: Okay.

> it is defining the TLLEI, etc.

[Qin]: Looks good to me.

> of" when talking about setting the length field in each message.

[Qin]: Okay.

> Nits sent directly to editors.

 [Qin]: Thanks.
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 2 Mar 2012 13:54:00 +0100

Hi Qin,

"I agree with your suggestion to the security section, that is to say the suppression rule is only 
applied when the packet are integrity protected and authenticated. I can put some text to make this clear."

I think you will have to explain/rationalise why receivers MUST  suppress feedback when receiving (unauthenticated) NACK packets (RFC 4585), whereas for 3rd party loss messages, feedback suppression is only required when the sender can be authenticated.
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: vrijdag 2 maart 2012 5:53
To: Robert Sparks; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

Hi, Robert:

Regards!
-Qin
----- Original Message -----
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Gonzalo Camarillo" <[email-masked]>
Sent: Friday, March 02, 2012 6:27 AM
Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

OLD Text:

"

"
New Text:

"

"

OLD text:

"

"

New Text:

"

"

[Qin]: Okay.

[Qin]: Looks good to me.

[Qin]: Okay.

 [Qin]: Thanks.

---

From: Qin Wu <[email-masked]>
Date: Fri, 02 Mar 2012 13:41:17 +0000

Hi, Tom:
I think TPLR should be dealt in the same way as NACK processing at the receiver.
And I check the section 3.5.2 of RFC4585 for the feedback suppression rule.You are
right,the reciever should suppress any feedback he understand, no matter whether this Feedback
is authenticated or not.
Maybe I am wrong to put additional restriction to that MUST statement. 
How about just remove such restriction, i.e.,"when the packet are integrity protected and authenticated".
I think putting a few discussion on what's required of such authentication in the security section will 
be enough.

Tom, does this address your comment?

Regards!
-Qin
________________________________________
发件人: Van Caenegem, Tom (Tom) [[email-masked]]
发送时间: 2012年3月2日 20:54
到: Qin Wu; Robert Sparks; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
主题: RE: [AVTCORE] AD review:    draft-ietf-avtcore-feedback-suppression-rtp-13

Hi Qin,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: vrijdag 2 maart 2012 5:53
To: Robert Sparks; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

Hi, Robert:

Regards!
-Qin
----- Original Message -----
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Gonzalo Camarillo" <[email-masked]>
Sent: Friday, March 02, 2012 6:27 AM
Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

OLD Text:

"

"
New Text:

"

"

OLD text:

"

"

New Text:

"

"

[Qin]: Okay.

[Qin]: Looks good to me.

[Qin]: Okay.

 [Qin]: Thanks.

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 2 Mar 2012 14:46:52 +0100

I cannot think of a reason to differentiate the receiver FB suppression behaviour  when receiving NACKs versus TPL messages, so this addresses my comment. Thx
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: vrijdag 2 maart 2012 14:41
To: Van Caenegem, Tom (Tom); Robert Sparks; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: 答复: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

Hi, Tom:
I think TPLR should be dealt in the same way as NACK processing at the receiver.
And I check the section 3.5.2 of RFC4585 for the feedback suppression rule.You are right,the reciever should suppress any feedback he understand, no matter whether this Feedback is authenticated or not.
Maybe I am wrong to put additional restriction to that MUST statement. 
How about just remove such restriction, i.e.,"when the packet are integrity protected and authenticated".
I think putting a few discussion on what's required of such authentication in the security section will be enough.

Regards!
-Qin

Hi Qin,

"I agree with your suggestion to the security section, that is to say the suppression rule is only applied when the packet are integrity protected and authenticated. I can put some text to make this clear."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: vrijdag 2 maart 2012 5:53
To: Robert Sparks; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

Hi, Robert:

Regards!
-Qin
----- Original Message -----
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Gonzalo Camarillo" <[email-masked]>
Sent: Friday, March 02, 2012 6:27 AM
Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

> says receivers MAY ignore third party lost reports, and then 
> confusingly says the SHOULD not ignore them. The security 
> considerations section says that receivers would be "well advised to 
> ignore" (effectively SHOULD ignore) third party reports unless they 
> are authenticated. This needs to be reconciled.
>

[Qin]: The reason to use "MUST" is it was suggested by the reviewer since RFC4585 that uses "MUST"
in the context of client feedback suppression. But I agree this description does not clarify in what circumstance to apply MUST. To be consistent with what we described in the security section, I agree with your suggestion to the security section, that is to say the suppression rule is only applied when the packet are integrity protected and authenticated. I can put some text to make this clear.

>
> 2) Why aren't RFC3711 and RFC5124 normative references? They're the 
> only offered tools for authenticating these messages in the document. 
> Even if other mechanisms might exist, there needs to be discussion 
> somewhere of what's required of this authentication, and the security 
> consideration sections of those documents would suffice.

> this trying to create a new registry with two initial values, or add 
> two values to an existing registry. If it's creating a new one, please 

OLD Text:

"

"
New Text:

"

"

OLD text:

"

"

New Text:

"

an attacker could cause packet loss disrupting an important part of a session, preemptively sending feedback suppression. An attacker that is also a receiver has enough information to suppress all the feedbacks from any other listeners that don't accept unauthenticated packets.

"

> Editorial suggestions:
>
> Please expand acronyms on first use (There are a _lot_ of acronyms, 
> many of which need references to where they are defined. Consider 
> adding a glossary so you can get that out of the way without 
> interrupting the flow of the text).

[Qin]: Okay.

> The protocol definition part of this document (section 4) is a bit of 
> a puzzle for a new reader. It would help to guide the reader through 
> the definition more directly. Here's a suggested modification - feel 
> free to ignore it:
>
> there. Each section defines how to populate the PT, FMT, length, SSRC 
> or packet sender, SSRC of media source, and FCI fields in that header."
>

[Qin]: Looks good to me.

> TBDs to TBD1 and TBD2, and say "length field in the" instead of 
> "length of" when talking about setting the length field in each message.

[Qin]: Okay.

 [Qin]: Thanks.
> Audio/Video Transport Core Maintenance [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 5 Mar 2012 11:03:05 +0100

Hi,

Agree that there should be no difference between authenticated and
non-authenticated messages.

> Or something else? Either way, please make the document internally 

My impression is that the paragraph 3 is about the RFC4585 based
suppression of sending additional RTCP message with the same meaning.

The text in in section 4 is that upon receiving a TPLR message a
receiver can treat it as an indication and chose to disregard it.
However, the criteria is vague. I also think the formulation of using
MAY plus should could just as well be replaced by a SHOULD formulation,
like: Receivers SHOULD react to TPLR messages unless ....

What does other say?

We still need an updated version prior to IETF LC.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Robert Sparks <[email-masked]>
Date: Mon, 05 Mar 2012 11:01:22 -0600

Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1), and it looks 
like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From 
your response below, I gather you
are trying to create a new registry instead of trying to put values in 
an existing registry, but your proposed
text still looks like it's trying to add a value to some table that 
already exists.

Where are you expecting IANA to put this new registry? Are you expecting 
it to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the 
registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first 
place?  Looking at the document,
it seems that you are only wanting to make these be standardized strings 
that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with 
the grammar defined in this
document.

I don't see any change in this revision to address the following comment:

On 3/1/12 10:52 PM, Qin Wu wrote:

<snip/>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 05 Mar 2012 12:21:35 -0600

Inline

On 3/5/12 11:01 AM, Robert Sparks wrote:
> Where are you expecting IANA to put this new registry? Are you 
> expecting it to be a subregistry of
> it seems that you are only wanting to make these be standardized 
> strings that can appear in
> the production of an SDP rtcp-fb-nack-param line. You've done that 
> with the grammar defined in this
> document.
Ah - that thought should have answered my question by itself instantly.
You are trying to put these values in this registry
<http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-15>

The text you added for -14 is close - I suggest this change:

OLD:
   This document instructs IANA to add two values in "ack" and "nack"
    Attribute Values registry for use with "nack"[RFC4585]:

NEW:

   This document instructs IANA to add two values to the '"ack" and "nack"
    Attribute Values' sub-registry [RFC4585] of the 'Session Description
    Protocol (SDP) Parameters' registry.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 5 Mar 2012 20:24:09 +0200

Hi Robert,

The IANA registration adds value to an existing registry called ack and nack
Attribute Values and this what the IANA section says " This document
instructs IANA to add two values in "ack" and "nack"
   Attribute Values registry for use with "nack"[RFC4585
<http://tools.ietf.org/html/rfc4585> ]:"

It is defined in RFC 4584 see below.

For use with both "ack" and "nack", a joint sub-registry has been set

   up that initially registers the following values:

   Initial value registration for the attribute values "ack" and "nack":

     Value name:     sli

     Long name:      Slice Loss Indication

     Usable with:    nack

     Reference:      RFC 4585.

     Value name:     pli

     Long name:      Picture Loss Indication

     Usable with:    nack

     Reference:      RFC 4585.

     Value name:     rpsi

     Long name:      Reference Picture Selection Indication

     Usable with:    ack, nack

     Reference:      RFC 4585.

     Value name:     app

     Long name:      Application layer feedback

     Usable with:    ack, nack

     Reference:      RFC 4585.

   Further entries may be registered on a first-come first-serve basis.

   Each registration needs to indicate the parameter name, the syntax of

   possible additional arguments, and whether the parameter is

   applicable to "ack" or "nack" feedback or both or some different

   "rtcp-fb" attribute parameter.  For each new registration, it is

   mandatory that a permanent, stable, and publicly accessible document

   exists that specifies the semantics of the registered parameter, the

   syntax and semantics of its parameters as well as corresponding

   feedback packet formats (if needed).  The general registration

   procedures of [3] apply.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
Sparks
Sent: Monday, March 05, 2012 7:01 PM
To: Qin Wu
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD
review: draft-ietf-avtcore-feedback-suppression-rtp-13)

Hi Qin -

I'm confused about the changes made to address Item 1), and it looks like
Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From your
response below, I gather you
are trying to create a new registry instead of trying to put values in an
existing registry, but your proposed
text still looks like it's trying to add a value to some table that already
exists.

Where are you expecting IANA to put this new registry? Are you expecting it
to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the
registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first place?
Looking at the document,
it seems that you are only wanting to make these be standardized strings
that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with the
grammar defined in this
document.

<snip/>

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we
follow

should suppress the further feedback for the same packet loss. Therefore I
like

---

From: Robert Sparks <[email-masked]>
Date: Mon, 05 Mar 2012 13:01:45 -0600

Yep - caught that already and suggested text that should be easier for IANA.

On 3/5/12 12:24 PM, Roni Even wrote:
>
> Hi Robert,
>
> The IANA registration adds value to an existing registry called ack and nack Attribute Values and this what the IANA section says "  This document instructs IANA to add two values in "ack" and "nack"
>     Attribute Values registry for use with "nack"[RFC4585  <http://tools.ietf.org/html/rfc4585>]:"
>   
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Robert Sparks
> *Sent:* Monday, March 05, 2012 7:01 PM
> *To:* Qin Wu
> *Cc:* [email-masked]; 
> *Subject:* [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 
> (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)
>
> Hi Qin -
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 06 Mar 2012 11:45:49 +0800

Hi, Magnus:
Thank for your valuable comments. Please see my replies inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Van Caenegem, Tom (Tom)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 05, 2012 6:03 PM
Subject: Re: [AVTCORE] AD review:draft-ietf-avtcore-feedback-suppression-rtp-13

> like: Receivers SHOULD react to TPLR messages unless ....

[Qin]: I agree with your proposed change.
and I have a further thinking, that is to say:

Do we have good reasons for receivers to to still send
feedback messages despite having been requested to suppress them?

If the anwer is no, I think another straightforward way to fix this issue is just remove the last sentence
in the paragraph 1 of section 4.

Magnus, what do you think of this?

---

From: Qin Wu <[email-masked]>
Date: Tue, 06 Mar 2012 13:06:29 +0800

Hi, Robert:
Thanks for your feedback. please see my replies inline below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Robert Sparks 
  To: Qin Wu 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; Gonzalo Camarillo 
  Sent: Tuesday, March 06, 2012 1:01 AM
  Subject: draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)

  Hi Qin -

  I'm confused about the changes made to address Item 1), 
  >> SHOULD ignore) third party reports unless they are authenticated. This 
[Qin]: Just for clarification.as you said, the text in section 3,4 and security sections seems to lack consistency.
I agree that section 3 and section 4 does lack consistency since according to RFC4585 feedback suppression rule,
the receiver should not ignore any feedback message including TPLR.
To fix this issue, my proposed change is to remove the last sentence in the 1st paragraph of section 4 
or use Magnus's proposed change.

Regarding the consistency between section 3,4 and Security section you pointed out. I think section 3.4 and Security consideration
section emphasize different thing. Section 3,4 emphasize TPLR MUST follow the same RFC4585 suppresion rule for NACK
while security section more emphasize that the feedback message must be sent from authenticated feedback sender. I think
this security rule should apply to all the feedback messages.

Does this Clarify?

  and it looks like Magnus still has questions
  about that too. Please resolve that by replying to Magnus' message.
[Qin]: Okay and have replied to Magnus in a separate message.

>The first part of the IANA registration section is still unclear. From your response below, I gather you
>are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
>text still looks like it's trying to add a value to some table that already exists.

[Qin]: Yes.

>Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
>the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to

[Qin]: Yes,this should be put in the ack and nack Attribute Values registry available at:
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml.
As described in RFC4585, policy rule should be based on a first-come first-serve.

>That said, why are you trying to put these in a registry in the first place?  Looking at the document,
>it seems that you are only wanting to make these be standardized strings that can appear in
>the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
>document.

[Qin]: That's not enough. RFC4585 has already assigned 4 initial values for for the attribute values "ack".
This document intends to assign two more new value for the attribute values "ack".

>I don't see any change in this revision to address the following comment:

[Qin]: Sorry, I forgot to incorporate the change and will fix this in the update.

---

From: Qin Wu <[email-masked]>
Date: Tue, 06 Mar 2012 13:08:12 +0800

Hi,Robert:
I will follow your suggested change. Thanks.

Regards!
-Qin
  ----- Original Message ----- 
  From: Robert Sparks 
  To: Qin Wu 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, March 06, 2012 2:21 AM
  Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)

  Inline

    I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions
    about that too. Please resolve that by replying to Magnus' message.

  OLD:

  NEW:

    <snip/>