Re: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-avpf-ccm-layered-03: (with COMMENT)

[Stephan Wenger <[e-mail]>]

Hi Stephen, 
please see inline.
Stephan




On 1/4/17, 15:45, "Stephen Farrell" <[e-mail]> wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-avtext-avpf-ccm-layered-03: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-avtext-avpf-ccm-layered/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>- MRST, MRMT, SRST - expand on 1st use please, not sure
>if there are more of those too

I also hope there are no other acronyms not spelled out.  A quick check did not reveal any.
The three acronyms you mention expand per section 3.7 of RFC 7656) as follows:
 
   SRST:  Single RTP stream on a Single media Transport

   MRST:  Multiple RTP streams on a Single media Transport

   MRMT:  Multiple RTP streams on Multiple media Transports


Anyone studying specs related to layered codec transport over RTP should be familiar with those, but I don’t mind spelling them out either.  RFC editor’s note?

>
>- Just checking: I assume when "repairing" something,
>that requires the same security properties be
>maintained or re-established and that there's no
>bidding down attack here that e.g. a middlebox 
>could mount here?

The word “repair” is used in the context of “source coding specific means”.  That means that the source encoder manipulates the coded bitstream in such a way that the problem is solved.  For and admittedly crude example, introducing intra macroblocks or picture (that do not depend on previous decoded pictures) instead of inter macroblocks or pictures (which do) constitute source coding specific means.  Doing so is transparent to all protocol layers other than the video encoding and decoding.  The repair information is included in the same RTP session as the regular media flow, and has the same security properties.  So yes, I see no option for a bid-down attack. 


>
>