[AVTCORE] Chair review of draft-ietf-avtcore-rtp-scip-03

[Bernard Aboba <[e-mail]>]

As part of the Publication Request process, the shepard is required to
certify that the  "document is needed, clearly written, complete, correctly
designed, and ready to be handed off".

The high level of interest in the document as well as its wide deployment
seems to indicate that it is needed, and my review of the SCIP protocol
documents seems to support that it is correctliy designed.  However, in
reading the specification as well as the SCIP codec documents, I have some
questions about the completeness of Section 4 RTP Payload Format.

Currently, the text is quite short:

4 <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip#section-4>.
Payload Format

   The RTP Packet content of SCIP traffic is dependent upon the SCIP
   session state.  SCIP secure session establishment uses protocols
   defined in SCIP-210 [SCIP210
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip#ref-SCIP210>]
to negotiate an application.  SCIP
   secure traffic may consist of the encrypted output of codecs such as
   MELPe [RFC8130 <https://datatracker.ietf.org/doc/html/rfc8130>],
G.729D [RFC3551 <https://datatracker.ietf.org/doc/html/rfc3551>],
H.264 [RFC6184 <https://datatracker.ietf.org/doc/html/rfc6184>], or
other media
   encodings, based on the application negotiated during SCIP secure
   session establishment.  SCIP traffic is highly variable and the bit
   rate specified in the SDP [RFC8866
<https://datatracker.ietf.org/doc/html/rfc8866>] is OPTIONAL since
discontinuous
   transmission (DTX) or other mechanisms may be used.  The SCIP payload
   size will vary considerably, especially during SCIP secure session
   establishment.

On reading this text, it may be unclear to the reader whether the
"media encodings" spoken of consist of codec payloads formatted as
specified in various RTP payload format documents (e.g. RFC 6184 for
H.264/AVC).  Is this the case, or is the cleartext to be encrypted
provided in some other format?


Overall, it seems to me that the specification could use a bit more of
an introduction to help provide context to the reader.  Here is an
enhanced Abstract for your consideration:


   This document describes the RTP payload format of the Secure
   Communication Interoperability Protocol (SCIP).  SCIP is an
   application layer protocol that defines the establishment of reliable
   secure end-to-end communications, including capabilities exchange
   and establishment and teardown of sessions. SCIP also supports
   exchange of voice, video and data in both P2P and conferencing
   scenarios. This includes support for secure chat, file exchange
   and whiteboard. This document defines the Session Description
   Protocol (SDP) and RTP parameters needed to support SCIP over RTP.

   The SCIP codec produces a bitstream that this specification endeavors
   to transport over RTP. Unlike other codecs, SCIP does not have its own
   upper layer syntax (e.g. no NAL units), but rather secures the output
   of the codecs that it uses (e.g. G.711, H.264, etc.). SCIP achieves
   this by encrypting codec output that has been previously formatted
   according to the relevant RTP payload specification (e.g. RFC 6184
   for H.264/AVC).

   Since SCIP includes its own facilities for capabilities exchange,
   it is only necessary to negotiate the use of SCIP within SDP
   Offer/Answer; the specific codecs to be encapsulated within SCIP
   are then negotiated via the exchange of SCIP messages.

   While SCIP provides for secure end-to-end communications, in
   conferencing scenarios the conferencing server is considered "trusted"
   so that it is granted access to cleartext media and can support
   operations such as mixing, transcoding or re-packetization,
   that are not permitted in "end-to-end" security schemes such as
   PERC or SFrame where the conferencing server is not trusted.