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

[Carsten Bormann <[e-mail]>]

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.

> 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?

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