RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec
Summary: Has 3 DISCUSSes. Needs 4 more YES or NO OBJECTION positions to pass.
# GEN AD review of draft-ietf-avtcore-rtp-scip-05 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/UqpTwkxRsJyLZHQA9FAqx8R0z4o). # Discuss I don't think this document should be published on the Standards Track without a normative reference to [SCIP210], and without that document being made available in some form during IETF review. If [SCIP210] cannot be made available, a way forward might be to publish this specification as an Informational RFC and to add explicit text about the limited review it has hence received by the IETF.
## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Grammar/style #### Section 5.3, paragraph 9 ``` TP in general. This responsibility lays on anyone using RTP in an application ^^^^^^^ ``` Did you mean "lies on"? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Thanks for working on this specification. My understanding is that SCIP is not a typical audio/video codec and intention here is to defice a payload format used along with other audio/video codecs. Thanks to Olivier Bonaventure for an excellent TSVART review. I would like to discuss the followings - - It is not clear to me what RTP profile should be used with this payload format. The RTP profiles are mentioned only in the security considerations. I think this specification would not be sufficient to be implemented without specifying the profile usage. I am getting that all the control messages are sent as SCIP messages, hence it needs to be clear on the RTP/RTCP usage. - This statement needs to be clarified more - "SCIP traffic is highly variable and the bit rate specified in the SDP [RFC8866] is OPTIONAL since discontinuous transmission (DTX) or other mechanisms may be used." What does this "highly variable" traffic mean? In what sense it is variable, variable bitrate? if this is highly variable how this would react to congestion and rate control? what bitrate is specified in the SDP? are you talking about the "b" parameter and interpretation of that? how is that to be interpreted in the session level and media level due to DTX? - it says - "a jitter buffer MAY be implemented in endpoint devices only" Given that "both discontinuous and continuous traffic are highly probable", a jitter buffer is a MAY? How to handle late loss or reordering? is it expected that no transmission error possible in the environment where SCIP operates? - what is the plan to include the changes agreed to with the TSVART reviewer? I mostly agreed with the resolution agreed with the reviewer and would like to see those changes in the document before we approve this document. That is the reason I am not bringing those topics back in this discuss. Please consider them as my discuss points as well.
Some further comments - - Please add a link to SCIP specification, I had hard time finding public description or documentation of SCIP codecs. - I think it would be great to provide the design principles behind SCIP with some details. This will be helpful for understanding the motivation and rtp format specified in the document.
# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Bernard Aboba for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status, this is related to my DISCUSS below. I hope that this review helps to improve the document, Regards, -éric # DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## Section 2 I am afraid that without free and public access to the IETF community (whether informational or normative) to the SCIP protocol itself, the IETF stream cannot publish any document (even informational or experimental) with the following assertion/claim `These capabilities include end-to-end security at the application layer, authentication of user identity,`. Suggest removing any such claim from the text.
# COMMENTS ## Abstract Is there a reason why is SDP expanded and not RTP ? ## Section 1 Unsure whether the following text has a place into an IETF RFC `This document provides a reference for network security policymakers, network equipment OEMs, procurement personnel, and government agency and commercial industry representatives.`. Suggest to remove it. I wonder to wonder whether the USA has left NATO ? The text `SCIP is presently implemented in United States and NATO` seems to indicate that the USA are not included in NATO. ## Section 1.2 The DTX acronym is expanded twice and never used. Suggest to remove it. ## Section 2 Per `Secure Communication Interoperability Protocol (SCIP) allows the negotiation of several voice, data, and video applications`, it appears that SCIP can also be used for *data*, but this document is only about video/audio. I.e., some text should explain to the reader what happens to the data. Please explain what is a STANAG or provide an informational reference to STANAG 5068. The reader will welcome explanations about the numbers in `scip/8000 and scip/90000` (e.g., by a reference to section 5) ## Section 3.1 Should there be informative references for MELPe, G.729D ? Is this subsection useful ? This document is about RTP payload and this subsection is more fit for the SCIP endpoints themselves. But, I am neither a transport nor an application expert, so, feel free to keep this subsection. # NITS The official name of the UNO member state is "United States of America" and not simply "United States".
Clearing my DISCUSS in order to not block document progress, however I trust the responsible AD will make sure it is addressed - see thread here: https://mailarchive.ietf.org/arch/msg/avt/SlWW2g74Rl-_41MzsYBMR-sZT4o/. ==== Previous ballot ===== DISCUSS Apologies for the delayed DISCUSS ballot. I just wanted to bring a process question up before the document moves forward. Since this document will be the reference RFC for two existing media type registrations, I wonder if the change controller should be changed to IETF instead of the SCIP wg. In practice this would mean that any change to the registration would need to go through the IETF, which might make inconsistency between the RFC of reference and the registrations less likely. COMMENT Thank you for the work on this document. I also read this document without reading the SCIP spec, as that spec is referenced informatively. Many thanks to Jim Fenton for his ART ART reviews: https://mailarchive.ietf.org/arch/msg/art/VUZVeNkbH40M6Oy_yqI7Om9Lvo0/ and https://mailarchive.ietf.org/arch/msg/art/HjMttUhTSLuOJZvrvALfHHbAl90/, and to the authors for addressing Jim's comments.
I have a couple small questions/nits with respect to this sentence in the abstract: SCIP is considered a tunneling protocol where the contents of the RTP payload will be indeterminant and should not be filtered or altered by the network. Question: do you actually mean “tunneling protocol“ and not “tunneled protocol“? When I read “tunneling protocol“, I think of something like LISP, IPSec tunnel mode, etc — a general purpose facility for transporting data. As far as I can tell from the rest of the spec, what you actually mean is that the SCIP payload is tunneled inside RTP. Please correct if appropriate. Nit: some of the dictionaries I consulted didn’t think that “indeterminant“ was a word at all. Some of the more open-minded dictionaries allowed that it was a word, but with a meaning that is somewhat… indeterminant, shall we say. Probably the RFC editor would suggest a change to this anyway, but consider changing to something closer to standard English if possible.
Hi, (1) p 0, sec 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 with secure session establishment parameters such as codec selection, encryption algorithms, security levels, and cryptographic initialization values. This document defines the Session Description Protocol (SDP) and RTP parameters needed to support SCIP over RTP. I'm somewhat wondering why this is being published as standards track rather then informational given that the underlying protocol is not openly available. Minor level comments: (2) p 4, sec 4.1. RTP Header Fields SCIP traffic may be continuous or discontinuous. The Timestamp field MUST increment based on the sampling clock for discontinuous transmission as described in [RFC3550], Section 5.1. The Timestamp field for continuous transmission applications is dependent on the sampling rate of the media as specified in the media subtype's specification (e.g., MELPe [RFC8130]). Note that during a SCIP session, both discontinuous and continuous traffic are highly probable. Therefore, a jitter buffer MAY be implemented in endpoint devices only but SHOULD NOT be implemented in network devices. Additionally, network devices SHOULD NOT repacketize SCIP packets. Please expand on what is meant by "repacketize SCIP packets". Regards, Rob
After giving this thought, I have to agree with Roman's position on this, and hence, I am joining him in an abstention on this document.
(Revised position) Thank you to Magnus Nystrom for the SECDIR review. I am abstaining on this document as it is unclear to me how to evaluate this document. Unlike most of the other recent “RTP Payload Format” document I could find, the text here avoids making a normative reference to a document formally describing a payload. Colloquially, I’m not sure how one can describe the “payload format of _something_” without normatively citing that _something_. Furthermore, the security basis for this document comes from this informative reference. The IETF 117 AVTCORE meeting discussions helpfully pointed out that RFC8817, a document I balloted on with a “No Objection” position, cites the codec it relies on informatively. I appreciate the inconsistency of my position. Simply put, I missed this detail in my review of RFC8817. I’ll note that RFC8817 does normatively cite SCIP, albeit the 2013 version, and this document references 2017. In my assessment, this approach meets the DISCUSS criteria of “[t]he draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively” per https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc. However, I won’t hold a document for reference mismatch as it is clear that the WG has discussed this issue in depth and there is IETF consensus on this way ahead. Additional comments ** I would have appreciated additional justification for the proposed standard (PS) status either in the text or in the shepherd write-up. The underlying codec is proprietary, neither available or intended for users outside of a closed consortium; and the need for standardization isn’t clear since this is intended for this closed consortium. MIME registrations can be done without a PS in the IETF stream. ** Section 1. This document provides essential information about audio/scip and video/scip media subtypes that enables network equipment manufacturers to include settings for "scip" as a known audio and video media subtype in their equipment. This enables network administrators to define and implement a compatible security policy It wasn’t clear which text in this document was intended to inform the definition of security policies. ** Section 5.1 and 5.2. The IANA review will clarify this, but the stated “Intended usage” of “Common, Government and Military” doesn’t seem consistent with the guidance in RFC6838 which says that: Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE.) ** Section 5.1. and 5.2. I concur with Francesca’s ballot which wonders why the IETF is registering a media type for which it has no change control and the challenges it might create.
[I support Roman's DISCUSS.]