Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10

Steve Lhomme <slhomme@matroska.org> Mon, 11 November 2019 13:00 UTC

Return-Path: <slhomme@matroska.org>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6712004D for <cellar@ietfa.amsl.com>; Mon, 11 Nov 2019 05:00:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wATquviHNz_e for <cellar@ietfa.amsl.com>; Mon, 11 Nov 2019 05:00:27 -0800 (PST)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C366D12020A for <cellar@ietf.org>; Mon, 11 Nov 2019 05:00:27 -0800 (PST)
Received: by mail-pg1-x52d.google.com with SMTP id 29so9441029pgm.6 for <cellar@ietf.org>; Mon, 11 Nov 2019 05:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NskYctN0cH2QM6D6tvHTSpjileKUrc9EkhXX6YFu5gE=; b=EJe5O+8Tfqoj0bgm8N7DWctOZ1rNfS4XTo5krowfZFlTBRoEzhMjSFDOMQ5YV9+5FB MCotpBHXBK7tZKQiYwo4Ou7xoV+QkqltM1Tur1NDVSnzzzjj28UmLwOMSfQxJrtK1tP8 OmilwOhA7gkL5XcxXUD/OPZEa2QmbTsCsXwGqaIt9+W/JWeZUDcYEsX0gUP6N4bAvcc9 jg6Osq7pnbHEvXT4DrlNC90AJ3Uk3M5Uq0BxgA3wte15DDiYqN6Kuz5G9fdbAmgbKR/x G32Ymid2oJ2taiOX+MXgPdG5Ip6gcT0ul4uKshJyTXxvbK0wqCJ2zqyYdjK3hQpLD6s2 lkbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NskYctN0cH2QM6D6tvHTSpjileKUrc9EkhXX6YFu5gE=; b=Hn+NJyaWKyIcK8/Xy5NUkZ9QUlfOOaobRYds1TPwl04x+/11ROSDLl9DuVUtuDIFpJ GEhtdna+obQiFeM0QGLtzCLEUOdjc6qsESPPFcqYTBJyuCpJGZIc6Bd/HacakP0pLmtZ 3rvSVrShfTIbSiLlPBMrUJKfMOQMbduklOErwkUZZYndZegeOWSoA6G0ABRrDBn4POpT Mr1IIA7H3E96ey9Eti6I+DT2qvQ1CWajOh3hVC/Rr4sh4uuY226p/vlt9d2zpA0jdi/N u2O23rO9UvKVYZKXieWqWB8ybUrVA/2Oh5WYm6URzmkcvzQcIEl7zIJ7mlUvTlC/SiHa bczA==
X-Gm-Message-State: APjAAAX/DMnWkgxSR+I+zF+qRcCRjePB+YTbJTH+hvrnKxMUKxgR22Wf 4H9qYfKHx9Su5tDssbopdhHl7zQJSPJA0HXZh31mwA==
X-Google-Smtp-Source: APXvYqyUJC8DNKR9J+WeSf9yGXFCX00X9xnpp2dN6iqW84rjc3dVj7tMrJU3TzWHjRX6VTA8nDKh1nwxTnfc+3o8/Q4=
X-Received: by 2002:a63:f1c:: with SMTP id e28mr6409637pgl.67.1573477227023; Mon, 11 Nov 2019 05:00:27 -0800 (PST)
MIME-Version: 1.0
References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <feca623f-380c-347d-5ab5-63fdc2322d0a@sandelman.ca> <bc6ef067-f360-4630-b6cf-f7b9fcb600f6@www.fastmail.com> <26528.1571940866@localhost> <c208f4e3-68bd-41ac-98ae-679f5c209ab3@www.fastmail.com> <CAOXsMFJO8Z1LW38AR6LFPsn86hUME9Ch_Xn3nip7mk0R4egj6g@mail.gmail.com> <BE6FD6D2-B44A-497A-AFAA-2234408C3BB9@fastmail.fm>
In-Reply-To: <BE6FD6D2-B44A-497A-AFAA-2234408C3BB9@fastmail.fm>
From: Steve Lhomme <slhomme@matroska.org>
Date: Mon, 11 Nov 2019 14:00:16 +0100
Message-ID: <CAOXsMFLw3zVphfvF9LLh_PNEiSk98oaJOFCxVL-qy_fUnbQf2w@mail.gmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Cc: Michael Richardson <mcr@sandelman.ca>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/JdaEzHwzUPo_TE2ZmUxuFtsx5uw>
Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 13:00:30 -0000

Hi,

Le lun. 4 nov. 2019 à 09:17, Alexey Melnikov <aamelnikov@fastmail.fm> a écrit :
>
> Hi Steve,
>
> > On 3 Nov 2019, at 10:04, Steve Lhomme <slhomme@matroska.org> wrote:
> >
> > Hi,
> >
> >> Le ven. 25 oct. 2019 à 17:37, Alexey Melnikov <aamelnikov@fastmail.fm> a écrit :
> >>
> >> Hi Michael,
> >>
> >>> On Thu, Oct 24, 2019, at 7:14 PM, Michael Richardson wrote:
> >>>
> >>> Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> >>>>> A decision as to who is the legitimate documentator of the (existing)
> >>>>> "webm" DocType would be up to the IESG.
> >>>
> >>>> Is "webm" will be worked on in this WG?
> >>>
> >>> No, not unless Google shows up with it!
> >>> WebM shares a container format with Matroska (being EBML), but we are not
> >>> trying standard it.
> >>
> >> So the IANA policy for this entry would be IESG Approval or RFC Required. Why do you want IESG to be involved in the decision to remove "Reserved" for "webm"? I would rather have Expert Review here, so that IESG doesn't need to decide.
> >
> > I'm not sure I understand the distinction between the two. The goal
> > here is to inform creators of an EBML format that "matroska" and
> > "webm" are known to be used elsewhere.
>
> The draft reserves 2 names, which is fine. The question is who is going to be authorized to change these reservations into proper registrations.
>
> The difference between IESG Approval and Expert Review is who is going to decide to mark an IANA registration entry as properly registered. IESG is a collection of 15 people, whose membership partially changes every year. Current IESG knows almost nothing about EBML. An appointed Expert would have more context to make a decision. So I think it makes sense for an Expert to handle this, instead of overloading IESG.
> (Maybe the following analogy would help: asking IESG is like asking a Board of Directors to make a technical direction. While IESG is ultimately responsible for the decision, it would prefer to delegate the decision to technical experts.)
>
> Does this make sense?

Yes, thanks a lot for the clarification. It does sound like the simple
choice would be to have an Expert Review for new DocTypes. Assigning a
name doesn't seem too hard, but if it means making sure the format is
actually making proper use of EBML then an "expert" look is needed.

Also there's still the question whether we should define a general
purpose binary format or just a binary format for Matroska. (see
Robert Sparks review and the issue I opened
https://github.com/cellar-wg/ebml-specification/issues/304) We may not
even have a IANA registry at all in the end.