Robert, thanks for your reviews of this document. I entered a No Objection ballot, supporting Adam’s DISCUSS about the abstract and requesting direct responses to Gen-ART reviews by email in the future. More below.
> On Dec 16, 2019, at 8:49 AM, Alexey Melnikov <alexey.melni...@isode.com> > wrote: > > 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> >> <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. > > I agree with Alexey here. Thanks, Alissa > 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/ > <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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
