Skip to main content

Last Call Review of draft-ietf-avtcore-cryptex-05

Request Review of draft-ietf-avtcore-cryptex
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-04-05
Requested 2022-03-15
Authors Justin Uberti , Cullen Fluffy Jennings , Sergio Garcia Murillo
I-D last updated 2022-04-05
Completed reviews Genart Last Call review of -05 by Linda Dunbar (diff)
Secdir Last Call review of -05 by Rifaat Shekh-Yusef (diff)
Artart Last Call review of -05 by Henry S. Thompson (diff)
Assignment Reviewer Henry S. Thompson
State Completed
Request Last Call review on draft-ietf-avtcore-cryptex by ART Area Review Team Assigned
Posted at
Reviewed revision 05 (document currently at 08)
Result Almost ready
Completed 2022-04-05
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]".


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]
as described in this document.  O/A procedures: SDP O/A procedures