[Sframe] Artart last call review of draft-ietf-sframe-enc-06

[Valery Smyslov via Datatracker <[e-mail]>]

Reviewer: Valery Smyslov
Review result: Ready with Issues

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.