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

[Adam Roach <[e-mail]>]

Dave --

Thanks for the quick response! The issues that the PR addresses look 
good to me. Two comments inline below.

On 12/17/19 9:27 AM, Dave Rice wrote:
>
>>
>> Abstract:
>>
>> I see that the Introduction has been revised to address Ben Campbell's AD
>> review comment regarding the document positioning itself as a 
>> general-purpose
>> data format rather than being scoped to its use in Matroska. The Abstract
>> still claims the much broader scope -- please update it to match the 
>> reduced
>> scope in the Introduction.
>>

I didn't see a response to this discuss point. See also the GENART 
review, which raises this issue in some detail.



>>
>> §17.1:
>>
>>> The VINT Data value of one-octet Element IDs MUST be between 0x01 and
>>> 0x7E.  These items are valuable because they are short, and need to
>>> be used for commonly repeated elements.  Values from 1 to 126 are to
>>> be allocated according to the "RFC Required" policy [RFC8126].
>>
>> This, combined with the values that are being registered, is extremely
>> confusing, and I don't know how IANA is supposed to understand what's 
>> going on
>> without reading and understanding the VINT bit encoding scheme (which 
>> is way
>> too much to ask of them). This is because of the document-wide practice
>> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead 
>> of their
>> data values (e.g., 63 or 0x3F), including in the initial registry in 
>> this section.
>>
>> Please either revise the prose to speak in terms of VINT-encoded values
>> (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration
>> tables to indicate the VINT data values (e.g., "0x3F" for CRC-32).
>
> I understand the request and the reason for it and am interested in 
> assessing rough consensus amongst the other authors before making this 
> change. These elements have been long-associated with these particular 
> vint expressions of the Element IDs, so I have some concerns that a 
> global change of Element ID reference from VINT to the Element Data of 
> that VINT would confuse readers.


Given that information, I imagine that the better path would be revising 
the IANA instructions to operate on VINTs ("MUST be between 0x81 and 
0xFE") instead of VINT element data. This should be very 
straightforward, as the encoding of VINTs results in contiguous ranges 
that should be easy for IANA to deal with.


/a