Re: [core] Robert Wilton's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT)

[Carsten Bormann <[e-mail]>]

On 2021-06-02, at 11:59, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-core-senml-versions-03: No Objection
> […]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Thanks for the this document.   Just a couple of minor comments.
> 
> It looked like the equation in section 2 was mucked up in the text version of
> the doc.  Presumably this will get fixed during the editing process:
> 
> I.e.,
>              __ 52                       fc
>   version = \         present(fc)&nbsp;⋅&nbsp;2
>             /__ fc = 0
> 

Indeed, this is an xml2rfc bug:

https://trac.ietf.org/trac/xml2rfc/ticket/641

(I will manually fix this before submitting the next version, if I remember to do that…  The RFC editor will, at the latest.)

>   Quantitatively, the expert could for instance steer the allocation to
>   not allocate more than 10 % of the remaining set per year.
> 
> Rather than setting this is a limit, I would suggest that it is better to set
> this as a target.  E.g., if it turns out that there is a good justification for
> an extension, it would be a shame if it had to be delayed by a year merely to
> fit into a somewhat arbitrary rate limiting scheme.

That actually was the intention of the weasel words “could”, “for instance”, “steer … to”.

I further clarified:
to not allocate ➔ to a target of not allocating


> Besides, if you end up with 53 different optional extensions, then I suspect
> that the bigger problem will be that there are too many variants of what is
> supported by different implementations which will reduce interop, and you'll
> probably want to end up with batches of extensions that are expected to be
> supported together, i.e., some sort of hybrid between completely independent
> extensions and a strict linear version scheme.

I agree, and that’s certainly a reason why we thought “49 bits is enough for everyone”.  Added a paragraph based on your text at the end of Section 2.1.

Changes now in https://github.com/core-wg/senml-versions/commit/989d37c

Grüße, Carsten