Skip to main content

Last Call Review of draft-ietf-cellar-ebml-13

Request Review of draft-ietf-cellar-ebml
Requested revision No specific revision (document currently at 17)
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
I-D 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 (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-cellar-ebml by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 13 (document currently at 17)
Result Not ready
Completed 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


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.