Subject: [core-parameters] Heads up for senml-versions

From: Jaime Jiménez <[email-masked]>
Date: Mon, 05 Apr 2021 15:03:32 +0300

Dear CoRE parameters experts,

this is just a heads up for the draft-core-senml-versions which has now finished WGLC. Please have a look at the new sub-registry being created and if you have any issues with the content please let the chairs of CoRE know.

https://tools.ietf.org/html/draft-ietf-core-senml-versions-02#page-4

We intend to submit to IESG shortly, so your potential comments would be checked during the IESG review process.

Ciao!
-- 
Jaime Jiménez

---

From: Esko Dijk <[email-masked]>
Date: Tue, 6 Apr 2021 08:13:29 +0000

Hi Jaime,

As an outsider to SenML I think the reason for doing this particular encoding in the version number is not yet well explained in the draft.  Somewhere it should state e.g. "re-purposing the version number is preferred to adding an additional feature-bitmask field in a version-11 format, because shorter to encode in average use cases".  

The registry looks okay from what I can tell!
For the sake of caution it could be useful to already reserve one feature code (e.g. the last one?) to indicate a far-future-version that doesn't encode a particular set of features but leaves open the door towards a completely different format (not using the feature codes) some day. 

Regards
Esko

-----Original Message-----
From: core-parameters <[email-masked]> On Behalf Of Jaime Jiménez
Sent: Monday, April 5, 2021 14:04
To: [email-masked]
Subject: [core-parameters] Heads up for senml-versions

Ciao!
-- 
Jaime Jiménez

_______________________________________________
core-parameters mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core-parameters

---

From: Jaime Jiménez <[email-masked]>
Date: Tue, 6 Apr 2021 14:12:44 +0300

Hi Dijk,

you actually might have a point there. While we have discussed it during
several IETF meetings we might have overlooked that explanation on the
draft itself. We hve added several clarifications and I am wondering if

@cabo you would be OK with adding that short motivation that Dijk is
suggesting. It could for example fit nicely on section 2.1. 

Ciao!
-- Jaime

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Apr 2021 10:36:58 +0200

Hi Esko,

> As an outsider to SenML I think the reason for doing this particular encoding in the version number is not yet well explained in the draft.  Somewhere it should state e.g. "re-purposing the version number is preferred to adding an additional feature-bitmask field in a version-11 format, because shorter to encode in average use cases”.

Re being short as a rationale: See first paragraph of 2.1 (OK, it’s called “efficient” there).

There is an infinite number of other approaches that solve this problem.
The specific one you mention really didn’t come to mind as it is inferior both to the one we chose and the introduction of a separate must-understand feature bit mask (no need to update the version number then).
I’m not sure we should discuss all these potential alternative approaches.

> For the sake of caution it could be useful to already reserve one feature code (e.g. the last one?) to indicate a far-future-version that doesn't encode a particular set of features but leaves open…

Well, we do have must-understand fields, so we can switch some features over to them whenever we like (possibly earlier than exhaustion of the version number bits).  (See parenthesis in penultimate paragraph of 2.1., which I think also at least partially covers the previous point.)

Grüße, Carsten

---

From: Esko Dijk <[email-masked]>
Date: Wed, 7 Apr 2021 12:19:38 +0000

Hi,

> Re being short as a rationale: See first paragraph of 2.1 (OK, it’s called “efficient” there).

I did see this rationale for efficient encoding of features; but to me (as an outsider) it only says that a bitmap to represent features is efficient and it does not say why the version field would need to be re-purposed for this. There must be some advantage w.r.t. leaving the version number field alone.   Maybe it's obvious that we cannot leave the version number to '10' in case some of the new features are included, but that it would need to be higher than 10, but to me that's not obvious. In case it is obvious to a user of RFC 8428 then of course we don't have to explain it.

By the way, I assume it is intentional that a SenML version 10 parser would never parse any SenML format object that uses a version > 10 ? See RFC 8428 4.4 requirement.
It seems a bit harsh that adding features would completely stop an older (v10) parser from processing the document. Again, there must be some reason here that I'm not understanding... 

> I’m not sure we should discuss all these potential alternative approaches.
Definitely not! I had assumed there would be one second-best alternative method only to consider, which was wrong. For me the most obvious choice of adding a feature bitmask is, well, to add a new feature bitmask field (which can encode features equally efficiently in principle) and not doing some wizardry with the version-number field. That's why I would expect a particular motivation for instead re-using the version field.

> Well, we do have must-understand fields, so we can switch some features over to them whenever we like
Ok so that removes the need to reserve any of the feature-codes, I think.

Best regards
Esko

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Wednesday, April 7, 2021 10:37
To: Esko Dijk <[email-masked]>
Cc: Jaime Jiménez <[email-masked]>; [email-masked]
Subject: Re: [core-parameters] Heads up for senml-versions

Hi Esko,

Grüße, Carsten