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

["Rob Wilton (rwilton)" <[e-mail]>]

LGTM.

Thanks,
Rob

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Carsten Bormann
> Sent: 03 June 2021 09:48
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; The IESG <[e-mail]>; [e-mail]; draft-ietf-
> [e-mail]
> Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-senml-
> versions-03: (with COMMENT)
> 
> 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