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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jun 03, 2021 at 12:28:38PM +0200, Carsten Bormann wrote:
> Hi Ben,
> 
> > On 2021-06-02, at 20:11, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-core-senml-versions-03: No Objection
> > […]
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Thanks, this is nicely written and a reasonable approach.
> > 
> > Section 3
> > 
> > I think I'm supposed to interpret this as being "the exact bit pattern
> > 1010 in the last four bits indicates support for the base SenML version
> > defined in RFC 8428; any other bitstring in that position cannot be
> > taken as an indication of support for the base version".  In other
> > words, we're still getting a one-bit signal, just encoded in four bits.
> > Is that right?  Or maybe just "it's an error to see any other values for
> > those four bits"?  (If so, do we reject the entire pack?)
> 
> Well, really, RFC 8428 only defines version 10.
> So we have no idea what another setting of those four bits would mean.
> The cop-out is the text
> 
>    These four reserved feature codes are not to be used with any
>    more specific semantics except in a specification that updates the
>    present specification.
> 
> which to me indeed means unless there is another specification updating this one, one would reject lsb ≠ 1010, except for a legacy application that, e.g. still supports SenML version 5.
> Does this need more text?  Suggestions welcome.

I was actually thinking less text, rather than more :)

Specifically, we could skip talking about Reserved1/Reserved3 always set
and Reserved0/Reserved2 always absent, and just say "the four least
significant bits set to 0b1010 indicate version 10" before contining to the
next sentence "These four reserved feature codes are not to be used..."

> > Section 5
> > 
> > I'd consider adding a sentence "the assignment of new feature bits is
> > done in a backwards-compatible manner, so existing implementations will
> > not erroneously assume support for a version (feature) that is defined
> > in the future" in the vein of an avoided security consideration.
> 
> You lost me here.  How can one assign bits in a non-backwards-compatible manner?

Assigning Reserved0 would be backwards-incompatible, in that it would allow
advertising support for a "version" that, when interpreted as a number,
produces a value less than 10.  So, a legacy 8428 implementation that
applies an ordering on version numbers would find that version lower than
the version 10 it supports, and presumably do something bad.

-Ben

> Of course, feature code 37 could mean "support all of feature code 36 except for feature foognorz, as well as feature barfgnup”.  When 36 and 37 are set, this means 36 + barfgnup.
> 
> We don’t even touch on how a receiving implementation could signal its feature support to a generating implementation; the underlying assumption is that most SenML is generated for eternity and not for a specific recipient.
> 
> Grüße, Carsten
>