Re: [AVTCORE] Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-08: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Eric,

Thank you for reviewing the document.

We have provided the public link to the SCIP-210 specification in the Informative reference section so that reader can have some idea of the different types of messages and data streams that might appear in the packets.  SCIP-210 can satisfy the assertion that it provides the security services stated in this draft.  This assertion is fundamental for the statement in the Security Consideration section regarding the use of (or not) Secure RTP.  This assertion is necessary for the entire concept of an encrypted and tunneled payload in this document.

The authors are perplexed how RFC 8817 (TSVCIS) was published given it is very similar to SCIP, including it being based on a non-public protocol specification as an Informative Reference.  We know that there is far more to the payload format that is not specified in that RFC.


Regards,
Dan Hanson
General Dynamics Mission Systems 

This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: Friday, February 2, 2024 8:34 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-08: (with DISCUSS and COMMENT)

----
External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Éric Vyncke has entered the following ballot position for
draft-ietf-avtcore-rtp-scip-08: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/



----------------------------------------------------------------------
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 ..."


----------------------------------------------------------------------
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".