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

Alexey Melnikov <> Mon, 16 December 2019 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72DA81200BA; Mon, 16 Dec 2019 05:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JbIvBhQRbj2m; Mon, 16 Dec 2019 05:50:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1972712007C; Mon, 16 Dec 2019 05:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1576504230;; s=june2016;; bh=DWwIjFtqEAc3Tp+gxllQh3iJ1pP0W8pEeBlBABngIRk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=YauT4nwQm+gwxOQutR/lsc1l3CuEaXV/4b+avWyD0+48jDdQIAxa/MmEMW18gngWdqNBVR OAKIS5cdkEeX8HhwiuYzR8siq7sLMLgkGdnn8qUjgA9Tual5qsT5xWwfcIstilUPIBzEaK tzvUy52zWiyzQWcEuTAoNV7oa9OBk4g=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Mon, 16 Dec 2019 13:50:30 +0000
To: Robert Sparks <>
Cc: General Area Review Team <>,, Michael Richardson <>
References: <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Mon, 16 Dec 2019 13:49:39 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------2BA4D3426CA91EF316968A40"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-cellar-ebml-14
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Dec 2019 13:50:36 -0000

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


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