Last Call Review of draft-ietf-avtcore-cryptex-05
review-ietf-avtcore-cryptex-05-artart-lc-thompson-2022-04-05-00

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