[Cellar] Second AD review of draft-ietf-cellar-ebml-10

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

Hi all,
I took over from Ben as the Area Director responsible for this WG.  My apologies that my review took so long.

Firstly, I am glad that you've implemented changes requested by Ben, as some of them were on my list of issues as well. I have a few comments of my own. Please respond to my review, so that we can collectively figure out what still needs fixing and which parts of the document I just misunderstood.

7.  EBML Element Types

   EBML Elements are defined by an EBML Schema which MUST declare one of

I think it would be helpful to readers to include a forward pointer to the section talking about EBML Schema here.

   the following EBML Element Types for each EBML Element.  An EBML
   Element Type defines a concept of storing data within an EBML Element
   that describes such characteristics as length, endianness, and
   definition.

11.1.  EBML Schema

   An EBML Schema is a well-formed XML Document that defines the

I think "well-formed XML" needs a normative reference here.

   properties, arrangement, and usage of EBML Elements that compose a
   specific EBML Document Type.

11.1.2.  <EBMLSchema> Element

   As an XML Document, the EBML Schema MUST use "<EBMLSchema>" as the
   top level element.  The "<EBMLSchema>" element MAY contain
   "<element>" sub-elements.

RFC 2119 MAY describes an implementation or deployment choice. So the above MAY doesn't seem to be appropriate. I suggest you change it to "can", as this is just a statement of fact.


11.1.5.2.  path

   The path defines the allowed storage locations of the EBML Element
   within an EBML Document.  This path MUST be defined with the full
   hierarchy of EBML Elements separated with a "/".  The top EBML

Yet below the ABNF is using \. I think one of these need to be fixed.

 PathDelimiter            = "\"

This is supposed to be the same as the above, right?

 EBMLElementOccurrence    = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence]
 EBMLMinOccurrence        = 1*DIGIT
 EBMLMaxOccurrence        = 1*DIGIT

Are there any upper limits on allowed values for these fields? Even if you don't encode them using ABNF, it would be good to mention them in an ABNF comment.

 VariableParentOccurrence = [PathMinOccurrence] "*" [PathMaxOccurrence]
 PathMinOccurrence        = 1*DIGIT
 PathMaxOccurrence        = 1*DIGIT

Same comment as above.

11.1.10.1.  label

   The label provides a concise expression for human consumption that
   describes what the value of the "<enum>" represents.

Is it worth adding a cross reference to the "lang" attribute here?


11.2.10.  DocTypeExtensionName Element

   description: The name of the DocTypeExtension to identify it from

I think the verb "differentiate" might be better than "identify" here.

   other DocTypeExtension of the same DocType+DocTypeVersion tuple.

12.  Considerations for Reading EBML Data

   If a Master Element contains a CRC-32 Element that doesn't validate,
   then the EBML Reader MAY ignore all contained data except for
   Descendant Elements that contain their own valid CRC-32 Element.

I don't fully understand your use of "MAY ... except ..." here.
Can you elaborate on why would an implementation ignore data contained in a Master Element and not ignore Descendant Elements, even if they own CRC-32 is valid?


   If a Master Element contains more occurrences of a Child Element that
   is not a Master Element than permitted according to the maxOccurs
   attribute of the definition of that Element then all but the instance
   of that Element with the smallest byte offset from the beginning of
   its Parent Element SHOULD be ignored.

I don't understand what this is is trying to say. If I have a Child Element with minOccurs = 2 and maxOccurs = 3, but the element appears 4 times: what would happen? I think the text above suggest to only use the first instance, which is possibly less than minOccurs.


16.  Security Considerations

   An EBML Reader MAY use the data if it considers it doesn't create any
   security issue.

I don't understand what this is trying to convey and how it can be complied with. Can you elaborate?
I suggest just deleting this sentence.


17.1.  CELLAR EBML Element ID Registry


   Four-octet Element IDs are numbers between 0x101FFFFF and 0x1FFFFFFE.
   Four-octet Element IDs are somewhat special in that they are useful
   for resynchronizing to major structures in the event of data
   corruption or loss.  As such four-octet Element IDs are split into
   two categories.  Four-octet Element IDs whose lower three octets (as
   encoded) would make printable 7-bit ASCII values (0x20 to 0x7F)

0x7F character is not considered printable. So I think this should be "(0x20 to 0x7E)". Ideally, you should also clarify that you want the whole range including 0x20 and 0x7E.

   MUST
   be allocated by the "Specification Required" policy.


17.2.  CELLAR EBML DocType Registry

   This document creates a new IANA Registry called "CELLAR EBML DocType
   Registry".

   DocType values are described in Section 11.1.3.1.  DocTypes are ASCII
   strings, defined in Section 7.4, which label the official name of the
   EBML Document Type.  The strings may be allocated according to the
   "First Come First Served" policy.

I think you need to be clearer on what you expect to appear on IANA's page. Do you expect a reference and/or description field in addition to a DocType name? I suspect you would also need the Change Controller field (who registered the value and can update the description).

   DocType string values of "matroska" and "webm" are RESERVED to the
   IETF for future use.  These can be assigned via the "IESG Approval"
   or "RFC Required" policies [RFC8126].

The last sentence is odd, but then I realized that you only reserve these two names and will attempt to assign them separately in the future. I suppose the current text is Ok.

Thank you,
Alexey