RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec
draft-ietf-avtcore-rtp-scip-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-08
|
09 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2024-03-08
|
09 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Magnus Nyström was marked no-response |
2024-03-05
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-03-05
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-03-05
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-03-04
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-03-04
|
09 | (System) | RFC Editor state changed to EDIT |
2024-03-04
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-03-04
|
09 | (System) | Announcement was received by RFC Editor |
2024-03-01
|
09 | (System) | IANA Action state changed to In Progress |
2024-03-01
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-03-01
|
09 | Cindy Morgan | IESG has approved the document |
2024-03-01
|
09 | Cindy Morgan | Closed "Approve" ballot |
2024-03-01
|
09 | Cindy Morgan | Ballot approval text was generated |
2024-03-01
|
09 | Cindy Morgan | Ballot writeup was changed |
2024-03-01
|
09 | Cindy Morgan | RFC Editor Note was changed to RFC Editor Note Please insert the following "IESG Note" at the front of the document prior to publication: This … RFC Editor Note was changed to RFC Editor Note Please insert the following "IESG Note" at the front of the document prior to publication: This IETF specification depends upon a second technical specification that is not available publicly, namely [SCIP210]. The IETF was therefore unable to conduct a security review of that specification, independently or when carried inside AVT. Implementers need to be aware that the IETF hence cannot verify any of the security claims contained in this document. |
2024-03-01
|
09 | Cindy Morgan | RFC Editor Note for ballot was generated |
2024-03-01
|
09 | Cindy Morgan | RFC Editor Note for ballot was generated |
2024-03-01
|
09 | Cindy Morgan | RFC Editor Note for ballot was generated |
2024-03-01
|
09 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2024-02-29
|
09 | Murray Kucherawy | Holding briefly to ensure the IESG Note text has IESG consensus. |
2024-02-29
|
09 | (System) | Removed all action holders (IESG state changed) |
2024-02-29
|
09 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup |
2024-02-29
|
09 | Murray Kucherawy | Ballot writeup was changed |
2024-02-26
|
09 | Martin Duke | [Ballot comment] Thanks to Olivier Bonaventure for the TSVART review. Sorry for the delay in my review. I have two comments: (4) Fig. 2 implies … [Ballot comment] 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? |
2024-02-26
|
09 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2024-02-23
|
09 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-02-14
|
09 | Éric Vyncke | [Ballot comment] 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 … [Ballot comment] 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 |
2024-02-14
|
09 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2024-02-14
|
09 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-09.txt |
2024-02-14
|
09 | Dan Hanson | New version accepted (logged-in submitter: Dan Hanson) |
2024-02-14
|
09 | Dan Hanson | Uploaded new revision |
2024-02-05
|
08 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing my discuss and comments. I believe, this specification is better and clear on the purpose. However, I think the abstract … [Ballot comment] 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. |
2024-02-05
|
08 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2024-02-02
|
08 | Éric Vyncke | [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. Alas, even after some email discussions … [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. Alas, even after some email discussions with the authors, the core of my discuss is still there. So, I cannot clear my discuss. Previous DISCUSS is at: https://mailarchive.ietf.org/arch/msg/avt/xFC3Ux9AfYt3e5T0GSzrasQe_j4/ # 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 3 and abstract 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 assertions/claims: - `SCIP is an application layer protocol that provides ... security services such as confidentiality and integrity protection` - `The SCIP protocol defined in SCIP-210 [SCIP210] includes ... security services such as end-to-end confidentiality and integrity protection.` Indeed, all IETF stream documents require that the IETF community was able to review it. The nature of SCIP standard has prevented such review, therefore, it is not possible for an IETF stream document to make those claims (that are probably correct). Suggest removing any such claim from the text or rephrasing them so that they do not appear as an IETF claim, e.g., "NATO claims that..." or "NATO certifies that ..." |
2024-02-02
|
08 | Éric Vyncke | Ballot discuss text updated for Éric Vyncke |
2024-02-01
|
08 | Lars Eggert | [Ballot comment] I would have been OK with this going forward as Informational, but for a Proposed Standard I have to agree with Roman that … [Ballot comment] 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. |
2024-02-01
|
08 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Abstain from Discuss |
2024-02-01
|
08 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-08.txt |
2024-02-01
|
08 | Dan Hanson | New version accepted (logged-in submitter: Dan Hanson) |
2024-02-01
|
08 | Dan Hanson | Uploaded new revision |
2024-01-31
|
07 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-07.txt |
2024-01-31
|
07 | Dan Hanson | New version accepted (logged-in submitter: Dan Hanson) |
2024-01-31
|
07 | Dan Hanson | Uploaded new revision |
2024-01-26
|
06 | Bernard Aboba | Added to session: interim-2024-avtcore-01 |
2023-12-05
|
06 | John Scudder | [Ballot comment] I have a couple small questions/nits with respect to this sentence in the abstract: … [Ballot comment] 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. |
2023-12-05
|
06 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-10-28
|
06 | Bernard Aboba | Added to session: IETF-118: avtcore Wed-0830 |
2023-09-19
|
06 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-06.txt |
2023-09-19
|
06 | Dan Hanson | New version accepted (logged-in submitter: Dan Hanson) |
2023-09-19
|
06 | Dan Hanson | Uploaded new revision |
2023-08-28
|
05 | Bernard Aboba | Added to session: interim-2023-avtcore-03 |
2023-08-04
|
05 | Éric Vyncke | [Ballot discuss] # É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 … [Ballot discuss] # É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. |
2023-08-04
|
05 | Éric Vyncke | [Ballot comment] # COMMENTS ## Abstract Is there a reason why is SDP expanded and not RTP ? ## Section 1 Unsure whether the following … [Ballot comment] # 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". |
2023-08-04
|
05 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2023-08-04
|
05 | Lars Eggert | [Ballot discuss] # 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). … [Ballot discuss] # 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. |
2023-08-04
|
05 | Lars Eggert | [Ballot comment] ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore … [Ballot comment] ## 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 |
2023-08-04
|
05 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2023-07-26
|
05 | Andrew Alston | [Ballot comment] After giving this thought, I have to agree with Roman's position on this, and hence, I am joining him in an abstention on … [Ballot comment] 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. |
2023-07-26
|
05 | Andrew Alston | [Ballot Position Update] Position for Andrew Alston has been changed to Abstain from No Objection |
2023-07-26
|
05 | Roman Danyliw | [Ballot comment] (Revised position) Thank you to Magnus Nystrom for the SECDIR review. I am abstaining on this document as it is unclear to me … [Ballot comment] (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. |
2023-07-26
|
05 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2023-07-24
|
05 | Roman Danyliw | [Ballot comment] Thank you to Magnus Nystrom for the SECDIR review. I am abstaining on this document as it is unclear to me how to … [Ballot comment] 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. It frames itself to be a “RTP Payload Format” document which seemingly has many analogs in the IETF stream. For example: -- RFC4578 (RTP Payload Format for H.261 Video Streams) -- RFC6184 (RTP Payload Format for H.264 Video) -- RFC7587 (RTP Payload Format for the Opus Speech and Audio Codec) -- RFC7798 (RTP Payload Format for High Efficiency Video Coding (HEVC)) -- RFC9134 (RTP Payload Format for ISO/IEC 21122) -- draft-ietf-payload-vp9 (RTP Payload Format for VP9 Video) -- draft-ietf-avtcore-rtp-v3c (RTP Payload Format for Visual Volumetric Video-based Coding) However, unlike all 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. 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. 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. |
2023-07-24
|
05 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to Abstain from Discuss |
2023-07-17
|
05 | Bernard Aboba | Added to session: IETF-117: avtcore Wed-2000 |
2023-03-29
|
05 | Bernard Aboba | Added to session: interim-2023-avtcore-02 |
2023-03-29
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-03-29
|
05 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-05.txt |
2023-03-29
|
05 | (System) | New version approved |
2023-03-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: Dan Hanson , Keith Maver , MikeFaller |
2023-03-29
|
05 | Dan Hanson | Uploaded new revision |
2023-03-25
|
04 | Francesca Palombini | [Ballot comment] Clearing my DISCUSS in order to not block document progress, however I trust the responsible AD will make sure it is addressed - … [Ballot comment] 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. |
2023-03-25
|
04 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to No Objection from Discuss |
2023-03-13
|
04 | Bernard Aboba | Added to session: IETF-116: avtcore Tue-0400 |
2023-02-03
|
04 | Bernard Aboba | Added to session: interim-2023-avtcore-01 |
2023-01-09
|
04 | Francesca Palombini | [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 … [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. |
2023-01-09
|
04 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to Discuss from No Objection |
2023-01-05
|
04 | Amy Vezza | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2023-01-05
|
04 | Robert Wilton | [Ballot comment] Hi, (1) p 0, sec … [Ballot comment] 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 |
2023-01-05
|
04 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-01-05
|
04 | Zaheduzzaman Sarker | [Ballot discuss] Thanks for working on this specification. My understanding is that SCIP is not a typical audio/video codec and intention here is to defice … [Ballot discuss] 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. |
2023-01-05
|
04 | Zaheduzzaman Sarker | [Ballot comment] Some further comments - - Please add a link to SCIP specification, I had hard time finding public description or documentation of SCIP … [Ballot comment] 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. |
2023-01-05
|
04 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2023-01-05
|
04 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. I also read this document without reading the SCIP spec, as that spec is referenced … [Ballot 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. |
2023-01-05
|
04 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2023-01-05
|
04 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2023-01-04
|
04 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-01-03
|
04 | Alvaro Retana | [Ballot comment] [I support Roman's DISCUSS.] |
2023-01-03
|
04 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2023-01-03
|
04 | Roman Danyliw | [Ballot discuss] (I conducted my review without access to [SCIP210]) ** Section 4. It isn’t clear what the format of the payload is from the … [Ballot discuss] (I conducted my review without access to [SCIP210]) ** Section 4. It isn’t clear what the format of the payload is from the description provided in this text beyond asserting that it is negotiated via SCIP-210 and that the SCIP codec is an encrypted bitstream. Are all details entirely opaque? If so, can the text please be more explicit in stating that. ** Section 6. RFC7202 appears to be cited here as a reminder to the reader that there are a variety of possible security solutions in the RTP ecosystem. My confusion is that it isn’t clear how this flexibility applies in the case of SCIP. It appears that there is tight coupling between the SCIP session negotiation and the embedded content in the RTP stream. Specifically, Section 4 notes that “The SCIP codec produces an encrypted bitstream that is transported over RTP.” Doesn’t the use of an SCIP payload (the blob generated by a SCIP codec) imply a set of security properties? Where are those formally documented? Section 2 hints at them being “end-to-end security at the application layer, authentication of user identity, the ability to apply different security levels for each secure session, and secure communication over any end-to-end data connection.” |
2023-01-03
|
04 | Roman Danyliw | [Ballot comment] Thank you to Magnus Nystrom for the early SECDIR review. ** Section 1. This document details usage of the "audio/scip" and "video/scip" … [Ballot comment] Thank you to Magnus Nystrom for the early SECDIR review. ** Section 1. This document details usage of the "audio/scip" and "video/scip" pseudo-codecs [AUDIOSCIP], [VIDEOSCIP] as a secure session establishment protocol and media transport protocol over RTP. It details how encrypted audio and video codec payloads are transported in RTP packets. I was unable to find the text which describes the “secure session establishment protocol” behavior beyond statements in Section 4 which way SCIP is used for that purpose. Could forward reference be provided? ** Section 2. Editorial. SCIP also provides several important characteristics that have led to its broad acceptance in the international user community. Consider scoping “international user community” a bit more narrowly as Section 1 states that the deployment is limited to “United States and NATO”. ** Section 2. These features include end-to-end security at the application layer, authentication of user identity, the ability to apply different security levels for each secure session, and secure communication over any end-to-end data connection. Is there a specific reference on how these security properties are realized and implemented? ** Section 2. Editorial. s/A combined Department of Defense/A combined US Department of Defense/ ** Section 2. Editorial. This RFC provides essential information about audio/scip and video/ scip media subtypes that enables network equipment manufacturers to include "scip" as a known audio and video media subtype in their equipment and 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. |
2023-01-03
|
04 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2023-01-02
|
04 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-12-29
|
04 | Amy Vezza | Placed on agenda for telechat - 2023-01-05 |
2022-12-28
|
04 | Murray Kucherawy | Ballot has been issued |
2022-12-28
|
04 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2022-12-28
|
04 | Murray Kucherawy | Created "Approve" ballot |
2022-12-28
|
04 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2022-12-28
|
04 | Murray Kucherawy | Ballot writeup was changed |
2022-12-25
|
04 | Murray Kucherawy | Reviewing an external reference. |
2022-12-25
|
04 | Murray Kucherawy | IESG state changed to Waiting for Writeup::AD Followup from Waiting for Writeup |
2022-12-19
|
04 | Olivier Bonaventure | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Olivier Bonaventure. Sent review to list. |
2022-12-19
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-12-14
|
04 | Bernard Aboba | Removed from session: interim-2022-avtcore-04 |
2022-12-13
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2022-12-13
|
04 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-avtcore-rtp-scip-04. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-avtcore-rtp-scip-04. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Media Types registry located at: https://www.iana.org/assignments/media-types/ the two registrations for: audio/scip and video/scip will have their references updated to [ RFC-to-be ]. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2022-12-10
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2022-12-10
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2022-12-07
|
04 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2022-12-07
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2022-12-07
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2022-12-05
|
04 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Olivier Bonaventure |
2022-12-05
|
04 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Olivier Bonaventure |
2022-12-05
|
04 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-12-05
|
04 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-12-19): From: The IESG To: IETF-Announce CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-scip@ietf.org, jonathan.lennox@8x8.com … The following Last Call announcement was sent out (ends 2022-12-19): From: The IESG To: IETF-Announce CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-scip@ietf.org, jonathan.lennox@8x8.com, superuser@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec) to Proposed Standard The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2022-12-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/ No IPR declarations have been submitted directly on this I-D. |
2022-12-05
|
04 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-12-05
|
04 | Cindy Morgan | Last call announcement was generated |
2022-12-02
|
04 | Murray Kucherawy | Last call was requested |
2022-12-02
|
04 | Murray Kucherawy | Ballot approval text was generated |
2022-12-02
|
04 | Murray Kucherawy | Ballot writeup was generated |
2022-12-02
|
04 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-12-02
|
04 | Murray Kucherawy | Last call announcement was generated |
2022-11-28
|
04 | Murray Kucherawy | One IANA matter for the WG to check on before Last Call. |
2022-11-28
|
04 | Murray Kucherawy | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2022-11-21
|
04 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2022-11-21
|
04 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
2022-11-17
|
04 | Bernard Aboba | Date: November 17, 2022 Request for Publication of: "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec" Document: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip WG: AVTCORE … Date: November 17, 2022 Request for Publication of: "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec" Document: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip WG: AVTCORE Type: Proposed Standard Shepard: Bernard Aboba Document Overview 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. 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. Shepherd Write-Up 1. Document History a. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The AVTCORE WG has discussed the "RTP Payload Format for the SCIP Codec" at multiple meetings. WG Last Call was announced on April 8, 2022 and concluded on May 8, 2022: https://mailarchive.ietf.org/arch/msg/avt/JKrPnCPMHgb6IIAfwyZhc-wF0a4/ As noted in the thread, 19 individuals indicated their support for advancement of the document, which is more than any AVTCORE WG document in recent memory. The Call for Adoption (CfA) announcement also elicited a large response (39 responses) as noted below: https://mailarchive.ietf.org/arch/msg/avt/vufEcYOXx7KWgfEx3tPoc0u2Wc0/ At this point, there is broad support for moving forward. b. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There have been questions relating to the architectural differences between SCIP and other "end-to-end" security schemes such as PERC and SFrame. Since SCIP includes support for capabilities exchange, it is only necessary to negotiate support for SCIP within SDP Offer/Answer; the details of the specific codecs encapsulated in SCIP (e.g. G.711, H.264) are handled within SCIP and do not need to be negotiated in SDP O/A. Since in SCIP the conference server is considered trusted and has access to cleartext media, SCIP does not require that conferencing servers support "codec independent forwarding". Once explained, these points have not been controversial. Reviewers have questioned whether the informative references to SCIP WG documents should be normative. While other RTP Payload Format documents have contained normative references to codec documents (e.g. draft-ietf-avtcore-rtp-vvc contains a normative reference to the VVC codec specification) in this case, the WG came to agreement that the references to SCIP WG documents should remain informative. Since the SCIP codec includes its own signaling as well as media transport functionality, the main requirement for intermediaries such SBCs is to avoid removing the SCIP codec within Offers and Answers, as well as to pass the SCIP RTP payloads unmodified. There have also been questions about how to obtain access to SCIP WG specifications. An email address has been provided which can be used to request the documents. Multiple WG participants (including the shepard) have requested the documents and have been provided with them. c. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No indications of extreme discontent or intent to appeal. d. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? SCIP over RTP has been implemented and widely deployed in endpoints, such as communication devices utilized by members of the North Atlantic Treaty Organization (NATO). One of the motivations for publishing this document as a Proposed Standard is to address interoperability issues with Session Border Controllers (SBCs). Since the SCIP protocol negotiates end-to-end secure communications, SBCs need to recognize SCIP audio/video in SDP as well as refraining from modifying the contents of the RTP payloads containing SCIP messages. Since those messages are secured end-to-end, attempts to transcode or otherwise modify the RTP payloads result in communications failure. 2. Additional Reviews a. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The SCIP protocol is defined by the SCIP WG, who have been active in the creation and maintenance of SCIP for more than a decade. Since SCIP over RTP has been widely deployed, the protocol as well as its transport over RTP is presumably well understood (except perhaps by SBC vendors). Several directorate reviews have been requested and completed: ARTART Review (Ready with Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-artart-early-fenton-2022-10-10/ SECDIR Review (Has Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-secdir-early-nystrom-2022-09-07/ GENART Review (Ready with Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30/ SDP Directorate Review: https://mailarchive.ietf.org/arch/msg/avt/7yqJcKcF_vWGQG0q7vxbRpeSpoU/ The authors made changes to the specification to response to these reviews. b. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document does not define any MIBs, YANG modules or URI types. Media sub-type allocations were approved for SCIP prior to submission of this document. See Section 5.1 ("audio/scip") and Section 5.2 ("video/scip") c. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? No YANG module. d. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No formal languages. 3. Document Shepherd Checks a. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The wide response to the Call for Adoption (CfA) and WGLC Announcements indicates that the document is needed. My review of the document is here: https://mailarchive.ietf.org/arch/msg/avt/8Kpakxp78_jnux9P2_iD0L4VkxQ/ The authors have made changes to the document to respond to those comments. https://mailarchive.ietf.org/arch/msg/avt/Y8XHPhLN5yRzt_BB7g3i-LY42gk/ b. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? As an RTP Payload format, it is not clear what Common Issues lists would apply, if any. c. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. d. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes. The authors have been asked to acknowledge their responsibilities under BCP 78 & 79, and have responded: https://mailarchive.ietf.org/arch/msg/avt/JaHArf3iaehSNoyEozJur3zU050/ Dan Hanson: https://mailarchive.ietf.org/arch/msg/avt/X6ZNoJ2Vbo2sgSQHPSOjw8dcwlM/ Keith Maver: https://mailarchive.ietf.org/arch/msg/avt/Lscy9_6tOm7QbBViHL2lahP3Fnk/ Michael Faller: https://mailarchive.ietf.org/arch/browse/avt/?gbt=1&index=Lscy9_6tOm7QbBViHL2lahP3Fnk e. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. The authors were queried for their willingness to be listed: https://mailarchive.ietf.org/arch/msg/avt/vZ3UmljJPlu3IqmDlAaHRnHC4Qc/ Each has responded with their willingness to be listed: Michael Faller: https://mailarchive.ietf.org/arch/msg/avt/zOJHt8z2tBvgsNX9dSn2ORZLkbQ/ Keith Maver: https://mailarchive.ietf.org/arch/msg/avt/4BgsmsMIiwi9eN6aA4MN-FYhiKE/ Dan Hanson: https://mailarchive.ietf.org/arch/msg/avt/hDDON7rzo1r_p2ElGJJKNABE04E/ f. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There do not appear to be any remaining I-D nits in the document: idnits 2.17.00 (12 Aug 2021) /tmp/idnits28550/draft-ietf-avtcore-rtp-scip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. No nits found. -------------------------------------------------------------------------------- g. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. The WG has discussed whether the references to the SCIP WG documents should be normative, and has concluded that they should be informative. h. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? The references to the SCIP WG documents are informative. An email address has been provided through which those documents can be requested. Multiple WG participants requested access and were provided with the documentation without fees. i. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. No normative downward references. j. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No normative references to documents that are not ready to be submitted to the IESG or are in an unclear state. k. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of any existing RFCs. l. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). IANA had previously reviewed and allocated the media sub-types requested in this document (Sections 5.1 and 5.2), so that further review did not appear necessary. m. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new IANA registries. |
2022-11-17
|
04 | Bernard Aboba | Responsible AD changed to Murray Kucherawy |
2022-11-17
|
04 | Bernard Aboba | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2022-11-17
|
04 | Bernard Aboba | IESG state changed to Publication Requested from I-D Exists |
2022-11-17
|
04 | Bernard Aboba | Document is now in IESG state Publication Requested |
2022-11-17
|
04 | Bernard Aboba | Tag Awaiting External Review/Resolution of Issues Raised cleared. |
2022-11-17
|
04 | Bernard Aboba | Date: November 17, 2022 Request for Publication of: "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec" Document: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip WG: AVTCORE … Date: November 17, 2022 Request for Publication of: "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec" Document: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip WG: AVTCORE Type: Proposed Standard Shepard: Bernard Aboba Document Overview 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. 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. Shepherd Write-Up 1. Document History a. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The AVTCORE WG has discussed the "RTP Payload Format for the SCIP Codec" at multiple meetings. WG Last Call was announced on April 8, 2022 and concluded on May 8, 2022: https://mailarchive.ietf.org/arch/msg/avt/JKrPnCPMHgb6IIAfwyZhc-wF0a4/ As noted in the thread, 19 individuals indicated their support for advancement of the document, which is more than any AVTCORE WG document in recent memory. The Call for Adoption (CfA) announcement also elicited a large response (39 responses) as noted below: https://mailarchive.ietf.org/arch/msg/avt/vufEcYOXx7KWgfEx3tPoc0u2Wc0/ At this point, there is broad support for moving forward. b. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There have been questions relating to the architectural differences between SCIP and other "end-to-end" security schemes such as PERC and SFrame. Since SCIP includes support for capabilities exchange, it is only necessary to negotiate support for SCIP within SDP Offer/Answer; the details of the specific codecs encapsulated in SCIP (e.g. G.711, H.264) are handled within SCIP and do not need to be negotiated in SDP O/A. Since in SCIP the conference server is considered trusted and has access to cleartext media, SCIP does not require that conferencing servers support "codec independent forwarding". Once explained, these points have not been controversial. Reviewers have questioned whether the informative references to SCIP WG documents should be normative. While other RTP Payload Format documents have contained normative references to codec documents (e.g. draft-ietf-avtcore-rtp-vvc contains a normative reference to the VVC codec specification) in this case, the WG came to agreement that the references to SCIP WG documents should remain informative. Since the SCIP codec includes its own signaling as well as media transport functionality, the main requirement for intermediaries such SBCs is to avoid removing the SCIP codec within Offers and Answers, as well as to pass the SCIP RTP payloads unmodified. There have also been questions about how to obtain access to SCIP WG specifications. An email address has been provided which can be used to request the documents. Multiple WG participants (including the shepard) have requested the documents and have been provided with them. c. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No indications of extreme discontent or intent to appeal. d. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? SCIP over RTP has been implemented and widely deployed in endpoints, such as communication devices utilized by members of the North Atlantic Treaty Organization (NATO). One of the motivations for publishing this document as a Proposed Standard is to address interoperability issues with Session Border Controllers (SBCs). Since the SCIP protocol negotiates end-to-end secure communications, SBCs need to recognize SCIP audio/video in SDP as well as refraining from modifying the contents of the RTP payloads containing SCIP messages. Since those messages are secured end-to-end, attempts to transcode or otherwise modify the RTP payloads result in communications failure. 2. Additional Reviews a. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The SCIP protocol is defined by the SCIP WG, who have been active in the creation and maintenance of SCIP for more than a decade. Since SCIP over RTP has been widely deployed, the protocol as well as its transport over RTP is presumably well understood (except perhaps by SBC vendors). Several directorate reviews have been requested and completed: ARTART Review (Ready with Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-artart-early-fenton-2022-10-10/ SECDIR Review (Has Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-secdir-early-nystrom-2022-09-07/ GENART Review (Ready with Issues): https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30/ SDP Directorate Review: https://mailarchive.ietf.org/arch/msg/avt/7yqJcKcF_vWGQG0q7vxbRpeSpoU/ The authors made changes to the specification to response to these reviews. b. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document does not define any MIBs, YANG modules or URI types. Media sub-type allocations were approved for SCIP prior to submission of this document. See Section 5.1 ("audio/scip") and Section 5.2 ("video/scip") c. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? No YANG module. d. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No formal languages. 3. Document Shepherd Checks a. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The wide response to the Call for Adoption (CfA) and WGLC Announcements indicates that the document is needed. My review of the document is here: https://mailarchive.ietf.org/arch/msg/avt/8Kpakxp78_jnux9P2_iD0L4VkxQ/ The authors have made changes to the document to respond to those comments. https://mailarchive.ietf.org/arch/msg/avt/Y8XHPhLN5yRzt_BB7g3i-LY42gk/ b. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? As an RTP Payload format, it is not clear what Common Issues lists would apply, if any. c. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. d. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes. The authors have been asked to acknowledge their responsibilities under BCP 78 & 79, and have responded: https://mailarchive.ietf.org/arch/msg/avt/JaHArf3iaehSNoyEozJur3zU050/ Dan Hanson: https://mailarchive.ietf.org/arch/msg/avt/X6ZNoJ2Vbo2sgSQHPSOjw8dcwlM/ Keith Maver: https://mailarchive.ietf.org/arch/msg/avt/Lscy9_6tOm7QbBViHL2lahP3Fnk/ Michael Faller: https://mailarchive.ietf.org/arch/browse/avt/?gbt=1&index=Lscy9_6tOm7QbBViHL2lahP3Fnk e. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. The authors were queried for their willingness to be listed: https://mailarchive.ietf.org/arch/msg/avt/vZ3UmljJPlu3IqmDlAaHRnHC4Qc/ Each has responded with their willingness to be listed: Michael Faller: https://mailarchive.ietf.org/arch/msg/avt/zOJHt8z2tBvgsNX9dSn2ORZLkbQ/ Keith Maver: https://mailarchive.ietf.org/arch/msg/avt/4BgsmsMIiwi9eN6aA4MN-FYhiKE/ Dan Hanson: https://mailarchive.ietf.org/arch/msg/avt/hDDON7rzo1r_p2ElGJJKNABE04E/ f. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There do not appear to be any remaining I-D nits in the document: idnits 2.17.00 (12 Aug 2021) /tmp/idnits28550/draft-ietf-avtcore-rtp-scip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. No nits found. -------------------------------------------------------------------------------- g. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. The WG has discussed whether the references to the SCIP WG documents should be normative, and has concluded that they should be informative. h. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? The references to the SCIP WG documents are informative. An email address has been provided through which those documents can be requested. Multiple WG participants requested access and were provided with the documentation without fees. i. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. No normative downward references. j. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No normative references to documents that are not ready to be submitted to the IESG or are in an unclear state. k. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of any existing RFCs. l. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). IANA had previously reviewed and allocated the media sub-types requested in this document (Sections 5.1 and 5.2), so that further review did not appear necessary. m. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new IANA registries. |
2022-11-17
|
04 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-04.txt |
2022-11-17
|
04 | (System) | New version approved |
2022-11-17
|
04 | (System) | Request for posting confirmation emailed to previous authors: Daniel Hanson , Keith Maver , MikeFaller |
2022-11-17
|
04 | Dan Hanson | Uploaded new revision |
2022-11-13
|
03 | Bernard Aboba | Added to session: interim-2022-avtcore-04 |
2022-11-13
|
03 | Bernard Aboba | Notification list changed to jonathan.lennox@8x8.com, bernard.aboba@gmail.com from jonathan.lennox@8x8.com because the document shepherd was set |
2022-11-13
|
03 | Bernard Aboba | Document shepherd changed to Dr. Bernard D. Aboba |
2022-10-17
|
03 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-03.txt |
2022-10-17
|
03 | (System) | New version approved |
2022-10-17
|
03 | (System) | Request for posting confirmation emailed to previous authors: Daniel Hanson , Keith Maver , MikeFaller |
2022-10-17
|
03 | Dan Hanson | Uploaded new revision |
2022-10-16
|
02 | Bernard Aboba | Added to session: IETF-115: avtcore Tue-0930 |
2022-10-10
|
02 | Jim Fenton | Request for Early review by ARTART Completed: Ready with Issues. Reviewer: Jim Fenton. Sent review to list. |
2022-10-07
|
02 | Barry Leiba | Request for Early review by ARTART is assigned to Jim Fenton |
2022-10-07
|
02 | Barry Leiba | Request for Early review by ARTART is assigned to Jim Fenton |
2022-10-07
|
02 | Barry Leiba | Requested Early review by ARTART |
2022-09-29
|
02 | Bernard Aboba | Notification list changed to jonathan.lennox@8x8.com because the document shepherd was set |
2022-09-29
|
02 | Bernard Aboba | Document shepherd changed to Jonathan Lennox |
2022-09-29
|
02 | Bernard Aboba | External review has indicated issues, so a revised I-D is needed. |
2022-09-20
|
02 | Bernard Aboba | Added to session: interim-2022-avtcore-03 |
2022-09-07
|
02 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. Submission of review completed at an earlier date. |
2022-08-30
|
02 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. |
2022-08-02
|
02 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-02.txt |
2022-08-02
|
02 | (System) | New version approved |
2022-08-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: Daniel Hanson , Keith Maver , MikeFaller |
2022-08-02
|
02 | Dan Hanson | Uploaded new revision |
2022-07-11
|
01 | Jim Fenton | Request for Early review by ARTART Completed: Not Ready. Reviewer: Jim Fenton. Review has been revised by Jim Fenton. |
2022-07-10
|
01 | Jim Fenton | Request for Early review by ARTART Completed: Not Ready. Reviewer: Jim Fenton. Sent review to list. |
2022-06-30
|
01 | Bernard Aboba | Added to session: IETF-114: avtcore Thu-1330 |
2022-06-30
|
01 | Stewart Bryant | Request for Early review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list. |
2022-06-22
|
01 | Bernard Aboba | Changed consensus to Yes from Unknown |
2022-06-22
|
01 | Bernard Aboba | Intended Status changed to Proposed Standard from None |
2022-06-12
|
01 | Tero Kivinen | Request for Early review by SECDIR is assigned to Magnus Nystrom |
2022-06-12
|
01 | Tero Kivinen | Request for Early review by SECDIR is assigned to Magnus Nystrom |
2022-06-06
|
01 | Peter Yee | Request for Early review by GENART is assigned to Stewart Bryant |
2022-06-06
|
01 | Peter Yee | Request for Early review by GENART is assigned to Stewart Bryant |
2022-06-06
|
01 | Barry Leiba | Request for Early review by ARTART is assigned to Jim Fenton |
2022-06-06
|
01 | Barry Leiba | Request for Early review by ARTART is assigned to Jim Fenton |
2022-06-06
|
01 | Bernard Aboba | Requested Early review by ARTART |
2022-06-06
|
01 | Bernard Aboba | Requested Early review by GENART |
2022-06-06
|
01 | Bernard Aboba | Requested Early review by SECDIR |
2022-06-06
|
01 | Bernard Aboba | SDP review requested: https://mailarchive.ietf.org/arch/msg/avt/MCyVOP876-VcvjAxzSM7JNO-p1w/ Security review requested: https://mailarchive.ietf.org/arch/msg/avt/pb2ZrMwLnC2UWWZ2dTLWGej2Dmk/ |
2022-06-06
|
01 | Bernard Aboba | Tag Awaiting External Review/Resolution of Issues Raised set. Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2022-06-06
|
01 | Bernard Aboba | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2022-05-25
|
01 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-01.txt |
2022-05-25
|
01 | (System) | New version approved |
2022-05-25
|
01 | (System) | Request for posting confirmation emailed to previous authors: Daniel Hanson , Keith Maver , MikeFaller |
2022-05-25
|
01 | Dan Hanson | Uploaded new revision |
2022-05-07
|
00 | Bernard Aboba | WGLC announcement: https://mailarchive.ietf.org/arch/msg/avt/JKrPnCPMHgb6IIAfwyZhc-wF0a4/ WGLC ends on May 8, 2022 |
2022-05-07
|
00 | Bernard Aboba | Tag Revised I-D Needed - Issue raised by WGLC set. |
2022-05-07
|
00 | Bernard Aboba | IETF WG state changed to In WG Last Call from WG Document |
2022-05-02
|
00 | Bernard Aboba | Added to session: interim-2022-avtcore-02 |
2022-03-20
|
00 | Bernard Aboba | Added to session: IETF-113: avtcore Fri-1000 |
2022-02-18
|
00 | Bernard Aboba | This document now replaces draft-hanson-avtcore-rtp-scip instead of None |
2022-02-18
|
00 | Dan Hanson | New version available: draft-ietf-avtcore-rtp-scip-00.txt |
2022-02-18
|
00 | (System) | WG -00 approved |
2022-02-18
|
00 | Dan Hanson | Set submitter to "Daniel Hanson ", replaces to draft-hanson-avtcore-rtp-scip and sent approval email to group chairs: avtcore-chairs@ietf.org |
2022-02-18
|
00 | Dan Hanson | Uploaded new revision |