[Cellar] AD review: draft-ietf-cellar-matroska

["Murray S. Kucherawy" <[e-mail]>]

Hi all,

With apologies for the long delay, this is my AD review of
draft-ietf-cellar-matroska.  This covers revision 14.  I'm going to be
returning it for further revision, but I think we're pretty close to
"ready" here.

My comments here are not in order of the document.

Section 27.1:

* Why are the elements in the table in decreasing order rather than
increasing order within each size group?  This isn't a showstopper, but I
found it peculiar.

* RFC 8126 requires, for a "Specification Required" registry, the
appointment of Designated Expert(s).  Do you have any to recommend?  They
don't need to be named in the document, but the next administrative step
will be to appoint those, so it's good to figure out whose names you plan
to submit.

* In addition to that, the document should (but currently does not) provide
guidance for the Designated Expert in terms of reviewing submissions for
the "Specification Required" ranges.  Is there a good reason not to include
such guidance?

* I don't think MUST/SHOULD language is appropriate here.  What you have is
fine, but it should all be lowercase.  If these are interoperability
concerns regarding the protocol, they belong in the earlier sections of the
document, not in instructions to IANA.

Section 27.2:

* This section is incomplete.  Please review RFC 8126.  It needs, at a
minimum, the registration procedures and the fields each registration needs
to have, any constraints on those, Designated Expert details where
applicable, etc.

Sections 27.3.1, 27.3.2, 27.3.3:

* "Interoperability considerations" (see Section 4.5 of RFC 6838) generally
assumes the intent is broad interoperability (otherwise why register?), so
I think we're looking for something different here.  Does this payload have
trouble crossing any particular environment boundaries?  Are earlier
versions of this specification, alive in the wild, incompatible with this
version?  Things like that.  Section 4.3, which makes reference to "legacy"
parsers, makes me think this is important to mention in the registration.

Section 27.3.3:

* The "deprecated aliases" field of this registration matches the name of
the registration.  That can't be right.

Section 1:

* While not necessary, you might want to include expansions and/or
informative references for HTTP, CIFS, and FTP.  (I actually had to look up
what CIFS is.)

* The final paragraph of this section doesn't seem to be necessary given
that this will be a Standards Track RFC published under the terms of BCPs
78 and 79, and there's already boilerplate saying so.

Section 2:

* Is this section meant to be retained on publication?  The second
paragraph seems important (and maybe this should be a section called
"Previous Versions"), but a standard that is also a work-in-progress will
probably raise some eyebrows.

Section 4:

* The two length parameters are numbers, and thus I think putting them in
quotes is unusual.

Section 4.3:

* The MUST summarizing three MUST NOTs isn't necessary.  Suggest "...,
these rules apply:".

Section 4.4:

* "A Matroska file SHOULD contain at least one Cluster Element."  What if
it doesn't?  Will things interoperate even when there are no Cluster
Elements?  Generally, SHOULD allows a choice, but we provide no guidance
here about when it's appropriate to deviate from that advice.  So a few
possibilities here:

- change it to MUST if you want to disallow the absence of Cluster Elements
- change it to MAY if either is fine
- say "normally contains" and avoid the problem

* The next SHOULD, about timestamps, has the same problem.  What if it's
some other timestamp?  Is there ever an instance when some other timestamp
is appropriate?  If not, maybe make this a MUST?

* The next SHOULD says "The Timestamp Element SHOULD be the first Element
in the Cluster it belongs to, or the second if that Cluster contains a
CRC-32 element".  Same problem; SHOULD allows it to be some other
timestamp.  Did you mean to allow this?  When might an implementer
legitimately do something else?

I'm going to stop mentioning problems with SHOULDs here; I suggest the time
be taken to review them all in this context.  (There are 111 of them.)

Section 5.1.2.1 (and all others that mention UUID):

* RFC4122 defines four variants of UUID.  Are all of them valid here?  Also
the "uuidrev" working group is proposing a new version of UUID; is there
anything to be considered for Matroska?

Section 5.1.2.8.3:

* Should "applied" be "applies"?

Section 5.1.2.9:

* Suggest changing "1.000.000" to "1000000" to match the default expression.

Section 5.1.3.5.2.2:

* I don't understand the "definition" field for this one.

Section 5.1.3.5.3:

* "timestampof" should be "timestamp of"

Section 5.1.4.1.1:

* Why "not encouraged"?  Do we have a compatibility problem we should call
out here, along with "NOT RECOMMENDED"?

Section 5.1.4.1.5:

* The SHOULD in here does not appear to describe an interoperability
concern.

Section 5.1.4.1.6:

* Same problem.

Section 5.1.4.1.7:

OLD:

NEW: