Ballot for charter-ietf-suit
Yes
No Objection
Note: This ballot was opened for revision 00-04 and is now closed.
Ballot question: "Do we approve of this charter?"
Adam’s comment about line breaks is still true in this version.
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 :-)
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.
The new version addresses the points I raised in the last round. Thanks!
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.
LGTM