Skip to main content

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