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

[Alexey Melnikov <[e-mail]>]

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.
>