RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec
draft-ietf-avtcore-rtp-scip-09
Yes
Murray Kucherawy
No Objection
Erik Kline
Jim Guichard
Paul Wouters
Abstain
Note: This ballot was opened for revision 04 and is now closed.
Murray Kucherawy
Yes
Erik Kline
No Objection
Francesca Palombini
(was Discuss, No Objection)
No Objection
Comment
(2023-03-25 for -04)
Sent for earlier
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.
Jim Guichard
No Objection
John Scudder
No Objection
Comment
(2023-12-05 for -06)
Sent
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.
Paul Wouters
No Objection
Zaheduzzaman Sarker
(was Discuss)
No Objection
Comment
(2024-02-05 for -08)
Sent
Thanks for addressing my discuss and comments. I believe, this specification is better and clear on the purpose. However, I think the abstract is too long now. It should focus on what this specification is doing not what SCIP does in the abstract. Much of what is written in the abstract can be put in the Introduction section.
Éric Vyncke
(was Discuss)
No Objection
Comment
(2024-02-14)
Sent
Thanks to the authors and to the AVTCORE WG for this document and for addressing my previous DISCUSS (documented at: https://mailarchive.ietf.org/arch/msg/avt/nQjGkmpOWPrH3YkrcZY0f_9dLOA/ ) I sincerely think that the current document reflects more accurately the separation between the IETF and NATA STANAG specifications. -éric
Roman Danyliw
(was Discuss)
Abstain
Comment
(2023-07-26 for -05)
Sent
(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.
Alvaro Retana Former IESG member
No Objection
No Objection
(2023-01-03 for -04)
Not sent
[I support Roman's DISCUSS.]
Martin Duke Former IESG member
No Objection
No Objection
(2024-02-26)
Sent
Thanks to Olivier Bonaventure for the TSVART review. Sorry for the delay in my review. I have two comments: (4) Fig. 2 implies that both Codec output and control messages can be sent unencrypted. Is that the intent? (4.2) Thanks for all the work on improving the congestion control section. As this document is focused on network interaction with SCIP, it would be useful to explain exactly what forms of network feedback will be consumed by SCIP congestion control or ABR. e.g. I assume packet drops are successful in getting SCIP to back off. But what about delay signals? ECN?
Robert Wilton Former IESG member
No Objection
No Objection
(2023-01-05 for -04)
Sent
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
Andrew Alston Former IESG member
(was No Objection)
Abstain
Abstain
(2023-07-26 for -05)
Not sent
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.
Lars Eggert Former IESG member
(was Discuss)
Abstain
Abstain
(2024-02-01 for -08)
Sent
I would have been OK with this going forward as Informational, but for a Proposed Standard I have to agree with Roman that the SCIP specification is an integral part of this and cannot simply be treated as a black box.