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

[Magnus Westerlund <[e-mail]>]

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
> 
> > On Dec 20, 2019, at 3:01 PM, Dave Rice <[e-mail]> wrote:
> > 
> > Hi Magnus,
> > 
> > > On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker <
> > > [e-mail]> wrote:
> > > 
> > > 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.
> > 
> > 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.
> > 
> > > ----------------------------------------------------------------------
> > > 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.
> > 
> > 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
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------