Re: [Cellar] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT)

[Dave Rice <[e-mail]>]

Hi Barry,

> On Dec 20, 2019, at 4:40 PM, Barry Leiba <[e-mail]> wrote:
> 
> Thanks, Dave, and I appreciate your addressing my concerns (and
> accepting most of my text!).  We're good on all the items you handled.

Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 is posted and addresses everything you listed below, except your comments on Section 10 and Section 17.1. Nudges to Michael Richardson and Steve Lhomme on these points.

Dave

> Barry
> 
> On Fri, Dec 20, 2019 at 4:08 PM Dave Rice <[e-mail]> wrote:
>> 
>> Hi Barry,
>> Thanks for your review. Comments are below, including nudges to Michael Richardson and Steve Lhomme for review. My comments below refer to work that is reviewable within a pull request at https://github.com/cellar-wg/ebml-specification/pull/316/files, though in a few parts below I call for greater discussion.
>> 
>>> On Dec 19, 2019, at 12:45 AM, Barry Leiba via Datatracker <[e-mail]> wrote:
>>> 
>>> Barry Leiba has entered the following ballot position for
>>> draft-ietf-cellar-ebml-15: No Objection
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> This was a very difficult read: I found a lot of the document to be convoluted
>>> and hard to follow, and I considered balloting Abstain, as I’m not sure that
>>> DISCUSS is appropriate for my complaints, but I can’t really say that I have
>>> “no objection”.  In the end I decided to go with a “No Objection” ballot, to
>>> call out the worst of the issues, and to hope that you will consider the
>>> changes I suggest and that others will follow the text more easily than I could.
>>> 
>>> — Section 4.1 —
>>> 
>>>  Each Variable Size Integer begins with a VINT_WIDTH which consists of
>>>  zero or many zero-value bits.  The count of consecutive zero-values
>>>  of the VINT_WIDTH plus one equals the length in octets of the
>>>  Variable Size Integer.  For example, a Variable Size Integer that
>>>  starts with a VINT_WIDTH which contains zero consecutive zero-value
>>>  bits is one octet in length and a Variable Size Integer that starts
>>>  with one consecutive zero-value bit is two octets in length.  The
>>>  VINT_WIDTH MUST only contain zero-value bits or be empty.
>>> 
>>> I found this very hard to follow, and had to read it several times before I
>>> understood what you’re getting at.  I found things such as “zero or many
>>> zero-value bits” to be confusing.  May I suggest alternative text, which
>>> describes the concept and then gets to the details?:
>>> 
>>> NEW
>>> Each Variable Size Integer begins with a VINT_WIDTH followed by a VINT_MARKER.
>>> VINT_WIDTH is a sequence of zero or more bits of value 0, and is terminated by
>>> the VINT_MARKER, which is a single bit of value 1.  The total number of bits
>>> (VINT_WIDTH and VINT_MARKER combined) is the number of octets of the Variable
>>> Size Integer.
>>> 
>>> Thus, the single bit “1” describes a Variable Size Integer with a length of one
>>> octet.  The sequence of bits “01” describes a Variable Size Integer with a
>>> length of two octets.  “001” describes a Variable Size Integer with a length of
>>> three octets, and so on, with each additional 0-bit adding one octet to the
>>> length of the Variable Size Integer. END
>>> 
>>> I, at least, find that easier to follow.  Does it work for you?
>> 
>> Yes, I think that’s helpful. I changed the term ‘begins’ and ‘describes’ to ’starts’, so there’s a little rewording but I have it now as:
>> 
>> NEW
>> Each Variable Size Integer starts with a VINT\_WIDTH followed by a
>> VINT\_MARKER. VINT\_WIDTH is a sequence of zero or more bits of value
>> `0`, and is terminated by the VINT\_MARKER, which is a single bit of
>> value `1`. The total number of bits (VINT\_WIDTH and VINT\_MARKER combined) is the number of octets in length of the Variable Size Integer.
>> 
>> Thus, the single bit `1` starts a Variable Size Integer with a length of one octet.  The sequence of bits `01` starts a Variable Size Integer with a length of two octets. `001` starts a Variable Size Integer with a length of three octets, and so on, with each additional 0-bit adding one octet to the length of the Variable Size Integer. END
>> 
>>> For the next paragraph, which limits the length under various circumstances, I
>>> suggest putting it in terms of the number of octets in the integer, rather than
>>> the number of bits in the VINT_WIDTH, which might be better put into Section
>>> 4.3, rather than 4.1.  Text such as, “A Variable Size Integer in an EBML Header
>>> can be at most 4 octets long, except [...] , where it can be up to 8 octets
>>> long,” is easier to understand than the text explaining limits on the number of
>>> bits in VINT_WIDTH.
>> 
>> I agree with your rewording but prefer to split this paragraph and move it to section 8.1 which pertains to the “EBML Header” and 8.2 which pertains to “EBML Body”. After rewording the content is:
>> 
>> Added to 8.1
>> Elements within an EBML Header can be at most 4 octets long, except for the EBML Element with Element Name EBML and Element ID `0x1A45DFA3` (see (#ebml-element)), which can be up to 8 octets long.
>> 
>> Added to 8.2
>> Within the EBML Body, the maximum octet length allowed for any Element ID is set by the EBMLMaxIDLength Element and the maximum octet length allowed for any Element Data Size is set by the EBMLMaxSizeLength Element.
>> 
>>> — Section 4.4 —
>>> Table 2 and the text that introduces it would be better if they talked about
>>> the integer that’s represented (2), rather than the binary value (0b10 in the
>>> text and 10 in the table), considering that it is a Variable Size INTEGER, yes?
>> 
>> That makes sense, I rewrote to focus on integer and parenthetically mentioned the binary value since the VINT is expressed in binary (though I added a hex representation as well).
>> 
>>> — Section 6.2 —
>>> 
>>>  An EBML Element with an unknown Element Data Size
>>>  is referred to as an Unknown-Sized Element.  A Master Element MAY be
>>>  an Unknown-Sized Element; however an EBML Element that is not a
>>>  Master Element MUST NOT be an Unknown-Sized Element.  Master Elements
>>>  MUST NOT use an unknown size unless the unknownsizeallowed attribute
>>>  of their EBML Schema is set to true (see Section 11.1.5.10).
>>> 
>>> This also seems confusing and perhaps contradictory because of how it uses the
>>> BCP 14 key words.  May I suggest this, which neither uses nor needs the key
>>> words?:
>>> 
>>> NEW
>>>  An EBML Element with an unknown Element Data Size
>>>  is referred to as an Unknown-Sized Element.  Only a Master Element
>>>  is allowed to be of unknown size, and it can only be so if the
>>>  unknownsizeallowed attribute of its EBML Schema is set to true
>>>  (see Section 11.1.5.10).
>>> END
>> 
>> I updated the section as suggested in the pull request.
>> 
>>> — Section 7.7 —
>>> 
>>>  The Master Element MAY also use an unknown length.
>>> 
>>> The “MAY” isn’t really correct, is it?  There are restrictions that make it not
>>> entirely optional, as noted in the next sentence.  I suggest not using BCP 14
>>> here, and just saying, “The Master Element may be of unknown length.”
>> 
>> I reworded this sentence with the prior one to avoid the use of MAY. The new paragraph is:
>> 
>> A Master Element MUST declare a length in octets from zero to VINTMAX or be of unknown length. See (#element-data-size) for rules that apply to elements of unknown length.
>> 
>>>  The Master Element contains zero, one, or many other elements.
>>> 
>>> Does this mean anything more than the simpler, “The Master Element contains
>>> zero or more other elements.”?  As written, one tends to ask what “many” means
>>> here.
>> 
>> I updated the sentence as suggested in the pull request.
>> 
>>> — Section 8.2 —
>>> 
>>>  The EBML Body MUST NOT contain any data that is not
>>>  part of an EBML Element.
>>> 
>>> Why is this repetition needed?  Doesn’t the similar sentence in Section 8 cover
>>> this?
>> 
>> True. I removed this repetitive statement.
>> 
>>> — Section 10 —
>>> 
>>>  An EBML Document handles 2 different versions: the version of the
>>>  EBML Header and the version of the EBML Body.  Both versions are
>>>  meant to be backward compatible.
>>> 
>>> I don’t see how that’s practical, as, taken strictly, it means you’ll never be
>>> able to make a significant change that is not backward compatible, so you’ll be
>>> stuck with errors or limitations forever.  Are you sure you won’t need to allow
>>> for incompatible versions at some point?
>> 
>> Nudging to Steve for review/comment. This part was written at:
>> https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11efbb6cdd70dd8021b8a05dc9
>> https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b1c3191e260707adf0c29dc
>> 
>>> — Section 17.1 —
>>> 
>>>  Values from 1 to 126 are to
>>>  be allocated according to the "RFC Required" policy [RFC8126].
>>> 
>>> Why did you choose that policy?  Are you aware that this allows registrations
>>> from non-IETF-stream RFCs?  In particular, anyone can get an RFC published in
>>> the Independent stream with a very light level of review.  Did you consider
>>> IETF Review, which requires an RFC in the IETF stream (including Informational
>>> and Experimental RFCs)?  Or even Standards Action, which requires
>>> standards-track RFCs?
>>> 
>>> The same comment applies to "matroska" and "webm" in Section 17.2.
>> 
>> Nudging to Michael, who recommended this policy here.
>> 
>> Best Regards,
>> Dave Rice
>> 
> 
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar