[Cellar] Ketan Talaulikar's Discuss on draft-ietf-cellar-codec-19: (with DISCUSS and COMMENT)

[Ketan Talaulikar via Datatracker <[e-mail]>]

Ketan Talaulikar has entered the following ballot position for
draft-ietf-cellar-codec-19: 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-cellar-codec/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

I have two aspects that I would like to discuss.

<discuss-1> Sections 8.1 and 8.2

2930	8.1.  Matroska Codec IDs Registry
2932	   This document defines registries for Codec IDs stored in the CodecID
2933	   element.  A CodecID is a case-sensitive ASCII string with a prefix
2934	   defined in Table 1.  The details of the string format are found in
2935	   Section 3.1.1.
2937	   "Matroska Codec IDs" are to be allocated according to the "Expert
2938	   Review" policy [RFC8126].
2940	   To register a new Codec ID in this registry, one needs a Codec ID
2941	   string, a TrackType value, a description, a Change Controller, and an
2942	   optional Reference to a document describing the Codec ID.

3226	8.2.  Matroska BlockAdditional Type IDs Registry
3228	   This document defines registries for BlockAdditional Type IDs stored
3229	   in the BlockAddIDType element.  The values correspond to the unsigned
3230	   integer BlockAddIDType value described in Section 5.1.4.1.17.3 of
3231	   [RFC9559].
3233	   "Matroska BlockAdditional Type IDs" are to be allocated according to
3234	   the "Expert Review" policy [RFC8126].
3236	   To register a new BlockAdditional Type ID in this registry, one needs
3237	   a BlockAddIDType unsigned integer, a BlockAddIDName string value, a
3238	   Change Controller, and an optional Reference to a document describing
3239	   the BlockAdditional Type ID.

First, the document creates two Expert Review registries and identifies the fields
that an applicant supplies, but it does not provide criteria that the
designated experts should use to accept, reject, or request changes to a
registration.

Please add designated-expert guidance covering; they might need to cover
the following:

* syntax and collisions with registered, reserved, deprecated, reclaimed, or
  historically deployed values;
* sufficient specification for independent implementation, including
  initialization data, field lengths, byte order, and malformed-input
  behavior where relevant;
* stability and accessibility of references;
* backward compatibility when an existing registration is changed;
* identification of an appropriate change controller; and
* security and resource-consumption implications.

The document should also state whether provisional registrations are
permitted and identify an appropriate public review venue that experts may
consult.

Second, the document does not explicitly request that the two new registries
be placed under the existing "Matroska" registry group.  Please make the IANA
request explicit, for example:

   IANA is requested to create the following two registries under the
   existing "Matroska" registry group.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please find below some additional comments inline in the idnits output of v19.
Look out for the <EoRv19> tag at the end to ensure you are seeing the complete
review.

369	3.2.  Recommendations for the Creation of New Codec Mappings
371	   Creators of a new Codec Mapping to be used in the context of
372	   Matroska:
374	   *  MUST assume that all Codec Mappings they create might become
375	      standardized, public, commonly deployed, or usable across multiple
376	      implementations.
378	   *  MUST employ meaningful values for CodecID and Codec Name that are
379	      not already included in the Matroska Codec IDs Registry, and are
380	      not otherwise known or suspected to be in use, even if they are
381	      not already registered.

<major> The text seems to permits a creator to select and deploy a CodecID that
is not registered, provided that it is not known or suspected to be in use. This
does not provide reliable global uniqueness.  Two independent creators can
select the same unregistered identifier for incompatible mappings, resulting
in ambiguous publicly deployed files.

Please require registration before a CodecID is used in publicly distributed
content or by multiple independent implementations.  If private or
experimental mappings are needed, please define a collision-resistant
procedure explicitly.  A provisional Expert Review registration seems
preferable because it retains one authoritative namespace and permits
collision checking before deployment.


2944	   Some Codec IDs values are deprecated.  Such Codec IDs are marked as
2945	   "Reclaimed" in the "Matroska Codec IDs" registry.

3191	     |           S_ASS |   17  | Advanced           | Reclaimed,     |
3192	     |                 |       | SubStation Alpha   | Section 3.5.7  |
3193	     |                 |       | Format             |                |
3214	     |           S_SSA |   17  | SubStation Alpha   | Reclaimed,     |
3215	     |                 |       | Format             | Section 3.5.7  |

<major> "Reclaimed" does not make clear whether these legacy Codec IDs are
permanently unavailable or can be assigned to a new mapping.  Reassignment
would be unsafe because existing files using S_ASS and S_SSA can remain in
circulation indefinitely and could then be interpreted using a new mapping.

Please use an unambiguous status such as "Deprecated -- MUST NOT be used for
new content and MUST NOT be reassigned", or mark the identifiers as
permanently reserved while documenting their historical use.  If
"Reclaimed" is retained, please define it explicitly as permanently
unavailable for reassignment.

Please take this review as someone who has not been involved in the past
CELLAR WG discussions and does not follow media codec work.

<EoRv19>