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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 02 Jun 2021 11:11:20 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-versions-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/

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

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.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Jun 2021 12:28:38 +0200

Hi Ben,

> On 2021-06-02, at 20:11, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> […]

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.

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Jun 2021 11:20:57 -0700

> 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..."

> 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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 22:22:47 +0200

> On 2021-06-04, at 20:20, Benjamin Kaduk <[email-masked]> wrote:
> 

I’m sorry, that did lead me to add some more text:

 For SenML Version 10 as described in {{-senml}}, the feature codes 0 to 3 are already in use.
 Reserved1 (1) and Reserved3 (3) are always present
 and the features Reserved0 (0) and Reserved2 (2) are always absent,
-yielding a version number of 10 if no other feature is in use.
+i.e., the four least significant bits set to 0b1010 indicate a version
+number of 10 if no other feature is in use.

> the version 10 it supports, and presumably do something bad.

Ah, but that just means Reserved1 and Reserved3 are useless (*), while Reserved0 and Reserved2 could be used like any other flag.  With Martin Duke’s comment, that maybe bears saying.  So I added

+(Note that Reserved0 and Reserved2 could be used in such a
+specification in a similar way to the way the feature codes 4 to 52
+are in the present specification.)

This should now be abundantly clear, at the risk of talking the reader into sound sleep.

Thank you for these comments; changes are in https://github.com/core-wg/senml-versions/commit/4aa6130

I’ll submit the -04 now.

Grüße, Carsten

(*) No, they aren’t entirely, but I’m too tired to explain the exact case in which they aren’t.  So I won’t write text about those.