Software Updates for Internet of Things
charter-ietf-suit-02

[Ballot comment]
Did we lose a milestone corresponding to draft-ietf-suit-manifest, in
the update?  I'm not sure if I'm just getting confused by the diff
formatting or not.

  To support a wide range of deployment scenarios, the formats are
  expected to be expressive enough to allow the use of different firmware
  sources and permission models.

This is perhaps a little too vague about what "different firmware
sources and permission models" would entail.  I'm wary of putting too
much detail into the charter, here, but perhaps we should say that the
WG will think about how much expressivity is desired on these axes?

I would also echo Éric's question about the well-known nature of the
"SUIT Status Tracker".

  In addition, the SUIT WG will work with the RATS WG to specify claims
  related to the SUIT Status Tracker that can be used to provide evidence
  in support of the architecture that has already been defined by the RATS
  WG.

What makes a claim "related to the SUIT Status Tracker"?
Also, the phrase "to provide evidence in support of the architecture"
leaves me uncertain if it says what it means -- are we supporting the
RATS architecture, or are we supporting something else while fitting
into the RATS architecture?

  - inclusion of MUD file as defined in RFC 8520.

grammar nit: singular/plural mismatch
Also, the MUD file is deifned in 8520, not inclusion of it.  We could
probably come up with an alternative phrasing that avoids the misparse.

  * A secure method for an IoT device to report on firmware update status.

This seems like it might be a new protocol, which is a little at odds
with the earlier portions of the charter that wanted to avoid new
transport or discovery mechanisms.

[Ballot comment]
It looks go to me and this is an important piece of work, so, go forward !

May I assume that "SUIT Status Tracker" is a well-know concept by the SUIT WG ?

Minor detail: is it worthwhile to mention work at the IETF hackathon in a WG charter ?

My only major concern is the last paragraph with "either the SUIT WG or the RATS WG will produce" : let's decide before re-chartering.

Some nits:
- should "KiB" be replaced by "kB" or "KB" ?
- s/with silicon vendors and OEMs/with vendors and OEMs/ ?

Added charter milestone "Decide with RATS WG in which working group the 'set of claims for attesting to firmware update status' document should be produced", due March 2022

[Ballot comment]
I don't understand why the charter wants to focus on specific serialization formats.

"The initial focus of this group will be development of the information model
for the contents of a manifest. Once there is general agreement on the
contents, the group will pick a small number of serialization formats such as
CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the
manifest."

Because it's IoT and it has to be efficient?
In the end, you care about a data model [RFC3444] as opposed to a information model [RFC3444], from which you can automate your serialization formats. Actually, the serialization of the day... Btw, This doesn't prevent to specify a default for interoperability.

I'll trust the responsible AD on that matter.

Changed charter milestone "Submit an initial "Manifest Format" to the IESG for publication as a Proposed Standard.", set description to "Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard."

Changed charter milestone "Calendar item: Release first version of manifest test tools as open source.", set description to "Calendar item: Second interoperability event at IETF 102.", set due date to July 2018 from April 2018

Changed charter milestone "Calendar item: Release first IoT OS implementation of firmware update mechanisms as open source.", set description to "Calendar item: First interoperability event at IETF 101.", set due date to March 2018 from June 2018

Changed charter milestone "Adopt an initial "Manifest Format" specification as WG item.", set description to "Adopt a manifest information model as a WG item.", set due date to March 2018 from December 2017

[Ballot comment]
I support Alissa's block position points.

I believe this work is critically important, and I hope we charter it. But it's the day before the telechat, and there are still ongoing questions on the SUIT list about the process and correct charter text. I suspect starting external review prior to the BoF, then making material changes has cause confusion. I think this would benefit from more time to work out the various elements of confusion. It might help to defer to the next telechat.

[Ballot block]
From reading the mailing list and doing my own review, there seem to be a bunch of open issues with this charter that would benefit from further discussion by interested participants before the WG gets chartered. Some of these might just be the result of lack of precision in the language used, but I think that is actually pretty important for clarity in a WG charter. The issues are:

1. On the list there seems to be disagreement about the interpretation of this text: "A lower number of formats is preferred to reduce code size for supporting decoders on devices receiving a manifest and to maximize interoperability of solutions." I also find myself confused by this (lower than what? is there some upper bound?).

2. Michael Richardson raised some good question about this text that seem like they warrant clarification, or at least a consensus call: "Software update solutions that target updating software other than the firmware binaries are also out of scope."

3. The milestones seem to use the term "Manifest format" to refer to something that the charter calls "the contents of a mainfest" (I think), in contrast to the multiple "formats" discussed in the charter. Given that there has also been discussion on the list about format vs. serialization and the absence of a data model specification, I think the charter and milestones would benefit from being crystal clear about what deliverables the WG is expected to produce and should use the same language throughout to name those deliverables.

4. This charter changed in some pretty important ways in the middle of the external review period, but was never re-sent to the new-work mailing list. There was also an error in the original announcement sent to new-work that could cause confusion (it said this was a re-charter). I asked for it to be re-sent but it doesn't look like it was. Since this is an important part of external review, I really don't think this step should be skipped.

I'm willing to move to ABSTAIN if no one agrees with me but I thought I would check to see if folks would be willing to take the time to sort out these issues.

[Ballot comment]
Some lesser issues:

5. The charter now talks about how the group may describe the use of existing discovery and transport mechanisms, but there are not associated milestone(s) for this work. Not sure if this is intentional or an oversight.

6. I agree with the folks on the list who have said that the background material about the IAB workshop and RFC 4108 should either be removed (preferably), or shifted around to the beginning of the text and edited so that it's clear that it's there for background purposes and not to constrain what the group does going forward.

[Ballot comment]
Thanks for doing this one.

For "While there are many proprietary firmware update mechanisms in use today, there is a lack of a modern interoperable approach of securely updating the firmware in IoT devices", perhaps "there is no modern interoperable approach allowing secure updates to firmware in IoT devices" might be easier to read.

Since you mention IoTSU, perhaps it's worth providing a pointer to the workshop report, now available as https://datatracker.ietf.org/doc/rfc8240/.

I wasn't able to connect "In particular this group aims to publish several documents, namely: - An IoT firmware update architecture that includes a description of the involved entities, security threats, and assumptions. - One or more manifest format specifications"

with

"The initial focus of this group will be development of the contents of a manifest".

So, the initial focus of the group is *not* to specify an architecture? I lack comprehension.

As an aside, as Adam noted, if that's a bullet list with two list elements, it would be clearer if it was formatted that way :-)

[Ballot comment]
This paragraph appears to be missing some line breaks:

> In particular this group aims to publish several documents, namely:
> - An IoT firmware update architecture that includes a description of the
> involved entities, security threats, and assumptions. - One or more manifest
> format specifications.

Changed charter milestone "Submit "Manifest Format" to the IESG for publication as a Proposed Standard.", set description to "Submit an initial "Manifest Format" to the IESG for publication as a Proposed Standard."

[Ballot block]
I would be "Yes", but I want to quickly discuss whether this should really limit work to a revision of RFC 4108 (which is CMS and thus ASN.1 based) versa some other format, like CBOR. I am not advocating that CBOR is the answer, but I want to understand why the restriction to CMS.

[Ballot comment]
I'm balloting No Objection but I think it would be useful to spend some more time refining the charter before sending it out for external review.

In addition to the question raised by Erik that has already been discussed, I wonder about constraining this to ASN.1. I've seen arguments on the list for why ASN.1 makes sense, but not why the WG should be prevented from working on other formats.

I also wonder about this text being overly limiting, given that the milestones additionally include specifying an architecture: "The purpose of this group is to produce a second version of RFC 4108 that reflects the current best practices."

Changed charter milestone "Submit "Architecture" to the IESG for publication as an Informational RFC.", set description to "Adopt "Architecture" to the IESG for publication as an Informational RFC."

[Ballot comment]
I think it'd probably be not necessary to mention the IOTSU workshop in the final charter. And instead of naming specific drafts in the charter, I'd prefer to see milestones that respectively could mention these as starting points.

[Ballot comment]
I think it'd probably be not necessary to mention the IOTSU workshop in the final charter. And instead of naming specific drafts in the charter, I'd prefer to see milestones that respectively could mention these as starting points. In any case, I'd actually like to see milestones added before approval as I would also like to know what the expected time line is.