Last Call Review of draft-ietf-avtcore-rtp-evc-05
review-ietf-avtcore-rtp-evc-05-secdir-lc-turner-2023-10-11-00

tl;dr: Just one issue that I'll get to after rambling for a bit.

This is your typical I-D for an RTP Payload Format for foo. It contains the
usual disclaimers in the Security Considerations section that are found in RTP
Payload Format RFCs:

* It's just about the payload format
* Read RTP & Options for Securing RTP
* There's no MTI security solution (see RFC 7202)
* Apps SHOULD provide a strong security mechanism

This I-D, like RFC 7798, also includes considerations for:
* DoS concerns during compression
* SEI
* End-to-End Security

Issue: If this I-D is like RFC 7798, why does RFC 7798 say this:

 Therefore, the usage of data origin authentication and data integrity
 protection of at least the RTP packet is RECOMMENDED, for example,
 with SRTP [RFC3711].

And this I-D says this:

 Therefore, the usage of data origin authentication and data integrity
 protection of at least the RTP packet is RECOMMENDED but NOT REQUIRED
 based on the thoughts of [RFC7202].

It seems like this I-D says it's similar to HEVC, but then adds this little bit
extra.  Also, "NOT REQUIRED" isn't BCP 14 language so it's probably got to be
changed by either rewording or making it lower case.

Editorial:
* s9 (missing period): s/avoid those/avoid those.