Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-rtp-evc-05

[Stephan Wenger <[e-mail]>]

Hi Sean,
Thanks for this review.

Short answer:
Regarding the “NOT RQUIRED issue: it was spotted also during Murray’s AD review and addressed by removing the NOT REQUIRED language.  See the attached email, towards the bottom.  We have addressed this issue in our working copy.
We will also address the nits.

Long answer:
We started this EVC draft from the VVC payload, RFC 9328, because VVC and EVC are closer than HEVC and EVC, and because 9328 has undergone its reviews not a year ago.  We though that doing so ought to make the review process easier, especially with non-core parts of the document.
We frequently refer to the HEVC payload, RFC 7798, because that format is, by now, deployed, and reasonably widely known in the implementer community.  For the implementer community, it seems to be better to refer to known, deployed technologies, than a brand-new RFC supporting a codec which many implementers are not yet familiar with.
Therefore, editorially and technically, the EVC payload draft is based on 9328 and not on 7798, even if it frequently cites 7798, for the reason mentioned.
RFC 9328 includes the offending “NOT REQUIRED” language.
RFC 9328 itself is based on 7798.  We payload people generally do not invent around the security considerations section but copy stuff that worked in the past; hence the 9328 security section started with the one of 7798.  I did not dig deeply into the archives, but the tinkering we saw between the 7798 and 9328 language was, IIRC, the result of SEC AD DISCUSSes.  They may not have made much sense to me, but then, who am I, talking about security?  When it comes to security, we trust the experts.
Clearly, the capitalization of “NOT” is not supported by RFC2119, and I agree with Murray’s comment in the attached email that even a “not RECOMMENDED” language, while consistent with RC2119, is redundant.  Hence, we will remove that language, which I think you are aiming towards as well.
I hope that addresses your concern; please let us know if not.
Thanks,
Stephan

From: Sean Turner via Datatracker <[e-mail]>
Date: Wednesday, October 11, 2023 at 16:53
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Secdir last call review of draft-ietf-avtcore-rtp-evc-05
Reviewer: Sean Turner
Review result: Has Issues

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.