Document: draft-ietf-avtcore-cryptex-05 Intended RFC status: Proposed Standard Review type: artart - Last Call review Reviewer: Henry S. Thompson Review Date: 2022-04-05 IETF Last Call Date: 2022-04-05 Summary: Almost Ready Caveat: I'm not a user of Secure Real-time Transport Protocol (SRTP) so am only reviewing this from a non-expert perspective. Minor points Section 5.2. Receiving "The implementation MAY stop and report an error if it considers use of this specification mandatory for the RTP stream." This reads oddly to me, as if it was originally written with 'may' rather than 'MAY'. I think what is meant is more like the following: Alternatively, in the presence of extensions but the absence of a matching value, an implementation MAY signal that it requires use of this specification by stopping and signalling an error. 6.1 Packet Structure I _think_ this diagram combines parts of diagrams taken from 3711 (Section 3.1 Figure 1) and 8285 (section 4.2). The latter is an _example_, and as such the "length=3" in the 6th line of the diagram doesn't really belong in something labelled generically "the SRTP packet is protected as follows", which seems to imply that what follows is a template for all such packets. Not sure whether the best way to fix this is by expanding the label ("for example an SRTP packet with 3 header extensions would be protected as follows") or by replacing "length=3" with something like "[number of extension headers]". Nits A number of acronyms are not glossed at first use, e.g. SRTP, SSRC, CSRC. If anyone reading this RFC can be expect to be familiar with them perhaps that's OK... Section 9.1 Is there a line break or two missing [in the plain text version] here-------------------------- | v as described in this document. O/A procedures: SDP O/A procedures