Telechat Review of draft-ietf-cellar-ebml-14
review-ietf-cellar-ebml-14-genart-telechat-sparks-2019-12-06-00

Request Review of draft-ietf-cellar-ebml
Requested rev. no specific revision (document currently at 17)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-12-17
Requested 2019-12-03
Authors Steve Lhomme, Dave Rice, Moritz Bunkus
Draft last updated 2019-12-06
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 (diff)
Assignment Reviewer Robert Sparks 
State Completed
Review review-ietf-cellar-ebml-14-genart-telechat-sparks-2019-12-06
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/XAGmb2Nc1-Rl3nlpQWTDvQqpgXM
Reviewed rev. 14 (document currently at 17)
Review result Not Ready
Review completed: 2019-12-06

Review
review-ietf-cellar-ebml-14-genart-telechat-sparks-2019-12-06

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

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

Document: draft-ietf-cellar-ebml-14
Reviewer: Robert Sparks
Review Date: 2019-12-06
IETF LC End Date: 2019-11-07
IESG Telechat date: 2019-12-19

This is just a copy of my LC review of -13 (to which I received no response):

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.