Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407)

["Murray S. Kucherawy" <[e-mail]>]

On Tue, May 18, 2021 at 10:59 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

>
> An "updates" or "bis" document just to resolve one or two errata might
>> raise some eyebrows.  How many do you want to handle?  Is there any pending
>> update you could fold into such a document?  Or to put it another way,
>> what's wrong with leaving it as a small number of errata for now?
>>
>> Whether you do a full "bis" document or an "updates" depends on how big
>> the aggregate change(s) you have in mind are.  I'm happy to be an advocate
>> for either; just depends on how big the final "diff" to the existing
>> document would be.
>>
>
> This is helpful.
>
> What we're looking at in this thread is a small number of errors for EBML
> (that haven't been entered as errata for the RFC yet), and a change to the
> IANA instructions for one of the registries in .
> https://www.iana.org/assignments/ebml/ebml.xhtml.
>
> Does that sound OK as an Updates RFC to you?
>
> (depending on the final "diff", of course!)
>

I'd have to see it to say for sure, but I would start this by writing an
"updates" RFC.  If it starts to become bigger than the kind of thing you
would be comfortable patching into some source code, you might consider
just doing a whole "bis" document that includes all of your corrections.  I
would surmise that the inflection point between the two choices is when the
size of the "updates" document exceeds the size that the diff of the "bis"
document would be.  When you cross that boundary, consider switching to the
latter.

Since you can always get the final XML back from the RFC Editor, doing a
"bis" document isn't as much of a burden as you might think.  The
datatracker certainly does make it easy for someone to just review the diff
to the previous RFC, and the IESG loves it when you make things easy on
them.  ;-)

I can anticipate, however, some resistance just on the basis that we're
already talking about a "bis" document for an RFC that's not even a year
old, so we should be prepared to talk about why this is necessary.

-MSK