Subject: [core] Advancing senml-versions

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Mar 2020 13:18:30 +0100

(No chair hat)

I just submitted draft-bormann-core-senml-versions-01

Htmlized:       https://tools.ietf.org/html/draft-bormann-core-senml-versions-01

It seems this document is needed to enable draft-ietf-core-senml-more-units to go forward, resolving the remaining IESG DISCUSS.

We haven’t really had a lot of discussion of the approach of this document outside the discussion of that DISCUSS.  Nonetheless, I’m going to ask the chairs to consider whether this can go through a working group adoption call now, so we can unlock -more-units, which is needed by other SDOs.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Mar 2020 18:52:34 +0100

> On 2020-03-06, at 13:18, Carsten Bormann <[email-masked]> wrote:
> 
> (No chair hat)
> 

I did, and it seems the chairs want some feedback before issuing a WGA call.  
So please do go ahead and feed back.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 19 Mar 2020 18:20:26 +0000

Hi Carsten,

On 19/03/2020, 17:52, "core on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:
> > Htmlized:> >
> > https://tools.ietf.org/html/draft-bormann-core-senml-versions-01
> >
> > It seems this document is needed to enable
> > draft-ietf-core-senml-more-units to go forward, resolving the
> > remaining IESG DISCUSS.
> >
> > We haven’t really had a lot of discussion of the approach of this
> > document outside the discussion of that DISCUSS.  Nonetheless, I’m
> > going to ask the chairs to consider whether this can go through a
> > working group adoption call now, so we can unlock -more-units, which
> > is needed by other SDOs.
>
> I did, and it seems the chairs want some feedback before issuing a WGA
> call.  So please do go ahead and feed back.

For the benefit of those who haven't followed the IESG ballot closely,
could you please elaborate on how Alissa's shift from DISCUSS to ABSTAIN
on senml-more-units changes the outlook on senml-versions?

Cheers, thanks!
--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Mar 2020 21:32:23 +0100

> on senml-more-units changes the outlook on senml-versions?

I don’t have the whole story yet, but more-units was approved today, so this takes the pressure out of moving forward with -versions.  Still, the remaining problem to be solved here is small but real, and we should check whether -versions is the right way to do that.
And Alissa has a point here, so we should take our liability to solve that quite seriously.

(Ari pointed out to me that it would be nice to have -versions as a WG document before more-units is published, which has -versions as an informative reference.  But that is a nice-to-have.)

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 20 Mar 2020 18:31:46 +0000

Hi Carsten,

On 19/03/2020, 20:32, "Carsten Bormann" <[email-masked]> wrote:
> > For the benefit of those who haven't followed the IESG ballot
> > closely, could you please elaborate on how Alissa's shift from
> > DISCUSS to ABSTAIN on senml-more-units changes the outlook on
> > senml-versions?
>
> I don't have the whole story yet, but more-units was approved today,
> so this takes the pressure out of moving forward with -versions.
> Still, the remaining problem to be solved here is small but real, and
> we should check whether -versions is the right way to do that.

Thank you for the info.

> And Alissa has a point here, so we should take our liability to solve

OK, I'll have a look at the document as well as to the IESG processing
trail then.

Cheers, t
--

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 23 Mar 2020 17:21:35 +0000

> OK, I'll have a look at the document as well as to the IESG processing

I had a look at the IESG processing and refreshed my memory with both
documents.

A few thoughts:

* The bitmap versioning scheme looks like a sensible choice.

* The small code-point space might become a problem in the future, but
  I'm not in a position now to foretell the amount of pressure the
  registry would be under.  Therefore, I trust the designer(s) that the
  proposed mechanism provides adequate scalability and I am happy with
  the "10%" rule-of-thumb for the expert.

* senml-more-units seems to sport normative language (just a MAY, but a
  2119 MAY nevertheless), however senml-versions is only referenced
  Informatively.  Am I confused or that is actually a problem?

All that considered, I'd take Ari's suggestion a bit further and:
a) Adopt senml-versions;
b) Make it a *normative* reference of senml-more-units.

It looks to me that the problem has been sufficiently debated already
and the identified solution is compact and clear enough that we could
reasonably take the risk and put senml-versions on the fast track.

Otherwise, adopt senml-versions and change that senml-more-units "MAY"
into a "could"?

cheers, thanks!
--