Subject: [Cellar] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 19 Dec 2019 06:02:26 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-cellar-ebml-15: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. Section 5:

   The Element ID is encoded as a Variable Size Integer.

    +-----------------------+-------------------------+---------------+
    | VINT Length in octets |  Range of Possible IDs  | Number of IDs |
    +=======================+=========================+===============+
    |           1           |       0x81 - 0xFE       |           126 |
    +-----------------------+-------------------------+---------------+
    |           2           |     0x407F - 0x7FFE     |        16,256 |
    +-----------------------+-------------------------+---------------+
    |           3           |   0x203FFF - 0x3FFFFE   |     2,080,768 |
    +-----------------------+-------------------------+---------------+
    |           4           | 0x101FFFFF - 0x1FFFFFFE |   268,338,304 |
    +-----------------------+-------------------------+---------------+

To me it appears that this whole section can't decide if the Element ID is
encoded integer using VINT or an VINT format octet sequence that is self
describing in length? If it is the first then the above quoted table would to
me state that the IDs are 1-126 for 1 octet, and the second two-octet
127-16382. But based on later section it is actually the later. As the ID
values defined in Section 11.2 for the various elements are actually the
encoded form rather than a representation of the Integer value encoded. This
needs to be clarified.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 5:

Any Element ID with the VINT_DATA
   component set as all zero values or all one values MUST be ignored.

What does it mean to ignore an Element ID in the general case. Can you really
say this in the general case, rather than state that it is not a valid Element
ID? Or is the intention that an Element ID with all data is the equivalent to
padding and simply skipped and a parser needs to expect to find the real
Element ID in the next octet sequence? Considering the Element Length that do
allow zero values and non-efficient encoding, if the element should be ignored
or not depends on the expected element to find by the parser.

I might have missed some later explanation of this, as I didn't manage to read
the whole document in detail.

---

From: Dave Rice <[email-masked]>
Date: Fri, 20 Dec 2019 15:01:42 -0500

Hi Magnus,

> On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 

Thanks, this topic came up in Adam Roach’s review [1] as well and ended with a use of an Element ID as a VINT format octet sequence. I have rewritten this section in the referenced pull request [2] according to your suggestions and comments.

I considered changing this sentence from saying that such an Element ID should be ignored to simply asserting that it is not valid; however the prior sentence "The bits of the VINT\_DATA component of the Element ID MUST NOT be all `0` values or all `1` values.” already makes this clear. Thus I simply removed the sentence in the second commit of the pull request. I think this sentence is okay to remove as there are later statements in Section 7.7 that make the same point more clearly about skipping invalid data.

Thanks much,
Dave

[1] https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8
[2] https://github.com/cellar-wg/ebml-specification/pull/315/files

---

From: Dave Rice <[email-masked]>
Date: Sun, 22 Dec 2019 15:50:26 -0500

Hi Magnus,

Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 is posted and should address all comments below. Thanks for your review.

Best Regards,
Dave Rice

> On Dec 20, 2019, at 3:01 PM, Dave Rice <[email-masked]> wrote:
> 
> Hi Magnus,
> 
> [1] https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8 <https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8>
> [2] https://github.com/cellar-wg/ebml-specification/pull/315/files <https://github.com/cellar-wg/ebml-specification/pull/315/files>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 29 Dec 2019 14:05:42 +0000

Hi,

Thanks, those changes do resolve my issue. I will clear my discuss. 

Cheers

Magnus

On Sun, 2019-12-22 at 15:50 -0500, Dave Rice wrote:
> Hi Magnus,
> 
> Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 is
> posted and should address all comments below. Thanks for your review.
> 
> Best Regards,
> Dave Rice
> 
> > Thanks, this topic came up in Adam Roach’s review [1] as well and ended with
> > a use of an Element ID as a VINT format octet sequence. I have rewritten
> > this section in the referenced pull request [2] according to your
> > suggestions and comments.
> > 
> > I considered changing this sentence from saying that such an Element ID
> > should be ignored to simply asserting that it is not valid; however the
> > prior sentence "The bits of the VINT\_DATA component of the Element ID MUST
> > NOT be all `0` values or all `1` values.” already makes this clear. Thus I
> > simply removed the sentence in the second commit of the pull request. I
> > think this sentence is okay to remove as there are later statements in
> > Section 7.7 that make the same point more clearly about skipping invalid
> > data.
> > 
> > Thanks much,
> > Dave
> > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------