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

["Alexey Melnikov" <[e-mail]>]

Hi,

On Tue, Dec 24, 2019, at 9:49 AM, Steve Lhomme wrote:
> Hi,
> 
> Le ven. 20 déc. 2019 à 22:08, Dave Rice <[e-mail]> a écrit :

> > > — 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?
> > >
> 
> For Matroska that's probably not an issue. It's OK if it's extended
> independently.
> 
> For the IDs in the EBML Header I don't have a strong opinion. If
> someone defines extra data in the header that only them plan to use,
> why not. If they make it public through the IETF it's already a better
> step. The problem is if there's a collision between 2 independent
> extensions or a planned addition to the format and an extension. In
> this case the first published should have priority.
> 
> There can be an issue if someone just comes and assign *all* the
> remaining one-octet IDs in their EBML extension and there's nothing
> left for the main EBML. Does the "light review" cover this kind of
> problem ? Otherwise we probably need to raise the level of scrutiny.

I missed this in my review and I am glad that Barry has noticed. In order to avoid issues that you mentioned, I suggest you either use "IETF Review" or "Specification Required" (the latter would require a stable specification, which might include a non IETF stream RFC, but also implies "expert review" which can catch issues like this). And after thinking about this for 10 seconds longer, I think "Specification Required" would be a better choice, as it means assigning a specific person (or group of people) who would be contacted before a new value can be registered.

Best Regards,
Alexey