Skip to main content

Last Call Review of draft-ietf-avtext-framemarking-13

Request Review of draft-ietf-avtext-framemarking
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-05-20
Requested 2022-03-25
Authors Mo Zanaty , Espen Berger , Suhas Nandakumar
I-D last updated 2022-05-10
Completed reviews Genart Last Call review of -13 by Gyan Mishra (diff)
Artart Last Call review of -13 by Martin Thomson (diff)
Opsdir Last Call review of -13 by Bo Wu (diff)
Secdir Last Call review of -13 by Carl Wallace (diff)
Opsdir Telechat review of -14 by Bo Wu (diff)
Assignment Reviewer Martin Thomson
State Completed
Request Last Call review on draft-ietf-avtext-framemarking by ART Area Review Team Assigned
Posted at
Reviewed revision 13 (document currently at 16)
Result Ready w/issues
Completed 2022-05-10
Apologies for delays; this review was assigned shortly before I went on a

This draft describes a means of providing meta-information about video flows. 
The design is sensible as a balance between what is revealed, while maintaining

I found the writing a little awkward at times; I'll provide a few notes below,
but I believe that this needs some careful attention to improving readability.


Section 3.3.2 through 3.3.4 contain a bunch of statements like this: " The
following shows the H265 [RFC7798] LayerID (6 bits) and TID (3 bits) from the
NAL unit header mapped to the generic LID and TID fields."  In this text, "the
following" seems to refer to the diagram, which is the only place that TID and
LID are shown.  Please use words to specify precisely how each of the fields in
the frame marking are populated.  Section 3.3.1 shows how this might be done.

"The header extension values MUST represent what is already in the RTP
payload." <-- either this is unenforceable or at least I can't imagine a switch
choosing to enforce it.  What harm comes if this is violated?  Poor forwarding
performance it seems is the worst possible outcome.  Consider dropping this
requirement and concentrating on the consequences of poor life choices.

The security considerations doesn't consider the potential privacy implications
of exposing this information.  This information might make traffic analysis


The title of the document should reflect that this is video-specific.

The last two bullets of the list in Section 1 aren't bullets, but new
paragraphs that follow the list.

Section 3 mentions I and D bits long before their definition.

In Section 3, " Such provisions SHALL be followed to recover the Frame Marking
RTP header extension of the original source packet. " is not a useful
application of RFC 2119 language.  Regular prose ("can") is fine as the user of
a redundancy stream might not want the frame markings.

Section 3.2 (and 3.3.x) effectively duplicates text from the definition of each
of the bits, D in particular.  This could be trimmed down.

Section 6 formatting seems to be garbled.