I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document describes SFrame - a general encryption and authentication framing for media data that can be used in various protocols.

Issues:
I have few issues with this document that are easy to address. Section 9 describes Application Responsibilities for using SFrame. I think that it lacks some important things (that might look obvious, but still need to be spelled out, IMHO).

1.  The section is silent that it is application responcibility to negotiate a cipher suite for SFrame. And if media traffic using SFrame is bi-directional, then there may be different cipher suites for each direction.

2. SFrame itself doesn't have any versioning. Despite that it is very simple, protocols tend to evolve, so there is no guranteee that SFrame v2 will never appear. Thus, it is application responcibility to negotiate use of a concrete version of SFrame. This can be done by various means, application developers should at least take this into account.

Nits:
1. Table 1 lists currently defined cipher sutes. While  Nk, Nn, and Nt are defined above in section 4.4, Nh is only defined below the table, in section 4.5.1. In addition, this section also use Nka, which is not present in the table. All this adds confusion for readers.

2. Section 6.2 describes potential problem that may occur when a new participant joins a conference. It is not clear for me why this section only mentions video frames. Unless I'm missing something, the same situation may occur with other media frames (e.g. audio), so explicitly mentioning only viseo frames adds confusion.

Considerations:
I also wonder whether SFrame needs so many reserved IANA codepoints. The draft allocates 5 codepoints out of 2^16 space. I can imagine that few tens more may be allocated in the future (even with fairly unrestrictive IANA policy as "Specification Required" is). Did you consider using 1-byte range for codepoints? I am mostly thinking about the use of SFrame in imaginated constrained protocols, where ciphersuites might be represented in 1-byte. This is just some considerations that might be worth to think about.