Ballot for charter-ietf-suit
Yes
No Objection
Note: This ballot was opened for revision 01-02 and is now closed.
Ballot question: "Is this charter ready for external review?"
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/ ?
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.