[art] Artart last call review of draft-ietf-avtext-framemarking-13

[Martin Thomson via Datatracker <[e-mail]>]

Reviewer: Martin Thomson
Review result: Ready with Issues

Apologies for delays; this review was assigned shortly before I went on a
vacation.

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
efficiency.

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.

Issues:

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
easier.

Nits:

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.