Reviewer: Robert Sparks Review result: Not Ready 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
