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.