Re: [Gen-art] Genart telechat review of draft-ietf-cellar-ebml-14

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art