Hi Robert,
Thank you for your review and my apologies for slow response:
On 06/12/2019 16:05, Robert Sparks via Datatracker wrote:
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.
CELLAR is chartered to do the latter.
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).
I don't find your proposal to NOT create an IANA registry to be a
compelling way of restricting use of EBML. Whether or not CELLAR is
chartered to do binary equivalent to XML, I don't think there is a need
to prohibit its use in other context, assuming it is a well defined format.
However I would like to know if the WG is expecting [many] other
registrations in the to-be-created IANA registry.
The abstract and introduction would need to be adjusted to
scope the purpose of the format to supporting the work of this group.
The Introduction was updated recently and it now says:
The goal of this document is to define a generic, binary, space-
efficient format that can be used to define more complex formats
using an EBML Schema. EBML is used by the multimedia container
Matroska (https://github.com/Matroska-Org/matroska-specification/).
The applicability of EBML for other use cases is beyond the scope of
this document.
This looks adequate to me.
The Abstract might be a bit more optimistic about scope of EBML. Can you
maybe suggest some improvements to the Abstract to make the scope clear?
Best Regards,
Alexey
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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
