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

[Roman Danyliw via Datatracker <[e-mail]>]

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

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.