Re: [AVTCORE] Roman Danyliw's Abstain on draft-ietf-avtcore-rtp-scip-05: (with COMMENT)

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

Roman,

We feel it is important to follow up with your recent comments.  The following responses were in the slide deck from IETF 117 but were not presented or discussed due to time constraints.

*       ... 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.
o       There is precedence: RFC 8817 TSVCIS has an informative reference to the TSVCIS specification
*       It wasn't clear which text in this document was intended to inform the definition of security policies.
o       Rev. 05 shifted the focus so that the SCIP payload should be supported by network devices - stated in the Introduction and Background
*       ... the stated "Intended usage" of "Common, Government and Military" doesn't seem consistent with the guidance in RFC6838 ...
o       The IANA Media Type submission form allows 'Additional Information' in the Intended Usage field.  We can remove "Government and Military" to avoid confusion.
*       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.
*       There is precedence: RFC 8817 TSVCIS is a government/military-only Media Type (and RTP payload) over which the IETF does not have change control authority
*       SCIP is requesting the same consideration
*       ... 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.
*       Again there is precedence: RFC 8817 TSVCIS is proprietary, neither available to or intended for users outside of a closed consortium
*       Based on non-public TSVCIS and SCIP specifications
*       RFC 8817 presents only a small portion of the RTP traffic - only the Narrowband MELP voice.  There are other payloads such as Wideband voice and NB/WB Data that are not presented.  And there are several control messages (e.g., preamble, EOM, etc.) that are transmitted that are not presented in RFC 8817.
*       Our main purpose is for network devices to support SCIP


Respectfully,
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: Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 26, 2023 2:18 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Roman Danyliw's Abstain on draft-ietf-avtcore-rtp-scip-05: (with 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.

Roman Danyliw has entered the following ballot position for
draft-ietf-avtcore-rtp-scip-05: Abstain

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/



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