Video Frame Marking RTP Header Extension
draft-ietf-avtext-framemarking-16

Thanks to Jonathan Lennox for the careful shepherd write up. When I read

“The document has been reviewed by WG members, and appears to be
complete insofar as it goes; however, there are concerns that it is
not sufficient for the uses cases for which it was intended.
Notably, the significantly more complex AV1 Dependency Descriptor
[https://aomediacodec.github.io/av1-rtp-spec/#appendix] addresses a
similar use-case much more thoroughly.”

It led me to wonder whether it would be a good idea to make some mention of this in the present document, for the edification of people referring to it who might not know about the more comprehensive solution?

Thanks for addressing my concerns regarding privacy considerations.

Thanks to Carl Wallace for the SECDIR review.

I support Paul’s DISCUSS for needing to discuss the privacy considerations.

My refinement on his position is whether there would be any circumstance where an attacker knowing that an encrypted payload has a I-frame (as revealed by this extension) would provide additional information in traffic analysis style attack (i.e., observing the changes in the rate of the I-frames).  A hypothetical scenario might be a variable rate codecs that reduces the I-frame rate in the absence of  motion in the video (to save bandwidth), and increases the I-frame rate when there is motion (to improve the fidelity of the video stream).  In such a circumstance, traffic analysis would reveal at least something about the encrypted payload (i.e., the presence or absence of motion)

Thanks for working on this specification. 

I hope to see the experimental results, but missing any description about what we are experimenting and any success criteria. I think it would be nice to have a section on suggested experiments. It could describe the intended usefulness of this extension and if successful becomes a standard track specification; also can document any security or privacy concern about the usage of meta information.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points.

Special thanks to Jonathan Lennox for the shepherd's detailed write-up including the WG "consensus" and the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric


## Section 1

It would be nice to expand "MCU".

## Section 2

Why having a section about normative language (moreover referring only to RFC 2119) in an experimental doc ?

# GEN AD review of draft-ietf-avtext-framemarking-14

CC @larseggert

Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/I-fIfxfS98c6BVePYcpjP3Hf7ng).

## Comments

### Boilerplate

This document uses the RFC2119 keywords "MUST NOT", "MUST", "RECOMMENDED",
"MAY", "SHOULD", and "NOT RECOMMENDED", but does not contain the recommended
RFC8174 boilerplate. (It contains a variant of the RFC2119 boilerplate.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 1, paragraph 3
```
 by recipients without prior frames, e.g switch on an intra-frame. * In many
                                     ^^^
```
The abbreviation "e.g." (= for example) requires two periods.

#### Section 3.5, paragraph 2
```
orm to common, fixed patterns of inter-layer dependencies and referencing str
                                 ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.5, paragraph 2
```
cies and referencing structures. Therefore it is RECOMMENDED to use LID and 
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

No issues with this document, that I generally found pretty easy to read.

In general, I'm pleased to see IETF working on solutions in this space (specifically, experimenting with what information can/should be exposed to middle boxes to improve the end-user experience whilst limiting the leakage of private information).  I'm not an expert in this area, but if exposing some limited information to middle boxes allows the video streams to remain encrypted, then this arguably ends up increasing overall end user privacy (e.g., compared with the middle box decrypting everything).

Regards,
Rob