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

Request Review of draft-ietf-cellar-ebml
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-11-07
Requested 2019-10-24
Authors Steve Lhomme, Dave Rice, Moritz Bunkus
Draft last updated 2019-11-04
Completed reviews Secdir Last Call review of -09 by Valery Smyslov (diff)
Genart Last Call review of -09 by Robert Sparks (diff)
Genart Last Call review of -13 by Robert Sparks (diff)
Secdir Last Call review of -13 by Valery Smyslov (diff)
Opsdir Last Call review of -13 by Shwetha Bhandari (diff)
Genart Telechat review of -14 by Robert Sparks
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-cellar-ebml-13-genart-lc-sparks-2019-11-04
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/9dpNgQqpTBmA8tkQ_bvEOT05gnE
Reviewed rev. 13 (document currently at 14)
Review result Not Ready
Review completed: 2019-11-04

Review
review-ietf-cellar-ebml-13-genart-lc-sparks-2019-11-04

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.