Last Call Review of draft-ietf-cellar-ebml-13
review-ietf-cellar-ebml-13-genart-lc-sparks-2019-11-04-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-cellar-ebml-13
Reviewer: Robert Sparks
Review Date: 2019-11-04
IETF LC End Date: 2019-11-07
IESG Telechat date: Not scheduled for a telechat

Summary: Not ready for publication as a Proposed Standard

I had previously reviewed version -09 of this document. Thanks for addressing
many of the issues I had raised at that time. My re-review has focused mainly 
on the diff between -09 and -13. It was surprisingly hard to make useful diffs 
between these versions, but it was possible to do so by separating out some 
reordered sections and comparing them separately.

I still find this document difficult to comprehend.

While not all of the issues I raised were addressed, I don't feel strongly
enough about them to repeat them. However, there is one major issue still
outstanding that is something the AD should handle.

(Attention Alexey) : It's not clear that this group is chartered to produce a
general purpose binary equivalent to XML. Instead, it appears to be chartered
to document FFV1 and Matroska. EBML as it is currently used for those things
needs to be documented, but rather than try to make it into a format that other
things besides the work of this group appears out of scope. If I'm correct,
then this document shouldn't need to create an IANA registry - it need only
document what the group needs (and if the group needs more later, it can update
this document). The abstract and introduction would need to be adjusted to
scope the purpose of the format to supporting the work of this group. My review
assumes a scope of "documenting these existing formats" rather than providing a
general purpose markup language. If I'm wrong and this group is chartered to
produce an alternative for other protocols to use, this needs review from
people who are more expert in that kind of representational design than me.