Last Call Review of draft-ietf-avtext-framemarking-13
review-ietf-avtext-framemarking-13-artart-lc-thomson-2022-05-10-00
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 | https://mailarchive.ietf.org/arch/msg/art/-wm3piTYU6AzzJmlVQs-Am-_Zxs | |
Reviewed revision | 13 (document currently at 16) | |
Result | Ready w/issues | |
Completed | 2022-05-10 |
review-ietf-avtext-framemarking-13-artart-lc-thomson-2022-05-10-00
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.