Early Review of draft-ietf-avtcore-rtp-scip-01
review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30-00
Request | Review of | draft-ietf-avtcore-rtp-scip |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Early Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2022-07-22 | |
Requested | 2022-06-06 | |
Requested by | Dr. Bernard D. Aboba | |
Authors | Dan Hanson , MikeFaller , Keith Maver | |
I-D last updated | 2024-07-24 (Latest revision 2024-02-14) | |
Completed reviews |
Secdir Early review of -02
by Magnus Nyström
(diff)
Genart Early review of -01 by Stewart Bryant (diff) Artart Early review of -01 by Jim Fenton (diff) Artart Early review of -02 by Jim Fenton (diff) Tsvart IETF Last Call review of -04 by Olivier Bonaventure (diff) Opsdir IETF Last Call review of -04 by Dan Romascanu (diff) |
|
Comments |
When submitting a review, please CC the AVTCORE WG (avt@ietf.org). As noted in the introduction, SCIP is a "pseudo-codec" that provides secure session establishment and transport over RTP. One of the goals of the document is to improve interop between SCIP endpoints and intermediaries such as SBCs and RTP relays. For example, SBCs have been observed to reject SDP Offers including SCIP, and some RTP relays have attempted to interpret or transcode SCIP RTP payloads, which is not helpful because they are encrypted and integrity protected. While SCIP is primarily used for secure audio communications, there is some experience with video (H.264) as well. In conferencing use cases, SCIP should be considered a "hop by hop" security service, in contrast to an "end to end" service such as SFrame. That is, SCIP is compatible with audio mixing or video MCU services, with the central conferencing server having access to cleartext media, thereby being considered "trusted". Note that the document has informative references to the following documents which can be made available upon request: [SCIP210] SCIP-210, "SCIP Signaling Plan", Revision 3.10, 26 October 2017, request access via email <ncia.cis3@ncia.nato.int>nt>. [SCIP214] SCIP-214.2, "Secure Communication Interoperability Protocol (SCIP) over Real-time Transport Protocol (RTP)", Revision 1.1, 18 April 2014, request access via email <ncia.cis3@ncia.nato.int>nt>. Bernard Aboba For the AVTCORE WG Chairs |
|
Assignment | Reviewer | Stewart Bryant |
State | Completed | |
Request | Early review on draft-ietf-avtcore-rtp-scip by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/UqpTwkxRsJyLZHQA9FAqx8R0z4o | |
Reviewed revision | 01 (document currently at 09) | |
Result | Ready w/issues | |
Completed | 2022-06-30 |
review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30-00
This simple document is adequate to register the media type as is. There are however a few small issues that could usefully be addressed. The introduction could usefully be expanded to include a couple of sentences on context and a direct reference to the protocols rather than a pointer to the IANA registry from which the reader has to get a pointer to the protocol. Bringing forward some material from the background to the introduction or merging the two sections would achieve this. The RFC 2119 language is not the latest version: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. I am surprised that the nits checker did not bring this up. In the text SCIP is sometimes capitalised and sometimes in lower case, they clearly mean different things but I could not see any text in the document that clarified the semantics of each variant. The references SCIP210 and SCIP214 are shown as informational. I assume that as much as anything this is because they are not widely available and strictly you could just treat them as opaque, but given they are fundamental to what you are standardising I would have expected them to be normative.