Ballot for draft-ietf-suit-manifest
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
[Updated for -32, I moved some comments to the DISCUSS area to get clear resolution as I didn't get any feedback on these, and they are important. Please let's have a discussion within a reasonable amount of time to get this document out finally] 1) informative vs normative Shouldn't [COSE_Alg] be a Normative reference? Shouldn't all of the [I-D.ietf-suit-firmware-*] references be normative? These are optional, but if required/used, very normative on how to do it. eg "if you want it encrypted, I-D.ietf-suit-firmware-encryption must be used". 2) MTI in an appendix Finally, Appendix D gives a summarize of the mandatory-to-implement features of this specification. That should not be in the appendix but in the main body of the document? Why not insert between section 8.4.x and 8.5 ? In my view, one should be able to implement a document without reading any appendici. 3) I find this text a bit confusing: [...] make the following guarantees: One of: 1. A [...] 2. [...] 3 [...] AND 1. Where [...] Is there a way to write this out better? 4) race condition? Recipient may issue each or every command concurrently until the Strict Order parameter is returned to True or the Command Sequence ends. This seems to invite race conditions if one concurrent command causes the Strict Order parameter to change? What else could change the Strict Order parameter midway a concurrent execution? Does this mean every command schedule has to check the Strict Order parameter? Should this be forbidden? 5) CDDL The CDDL contains: suit-reporting-bits = &( suit-send-record-success : 0, suit-send-record-failure : 1, suit-send-sysinfo-success : 2, suit-send-sysinfo-failure : 3 ) Doesn't this mean 2 bits are used to declare a bool? What if these contradict? Why not use a single bit?
Thanks for clearing up the IANA-related DISCUSS I was holding. The shepherd writeup doesn't include the reason that PS is the right status here. "nint" appears in Appendix B, but I don't know what that is. Where's it defined?
Murray had previously had this text on my behalf in his discuss: """ From Orie Steele, incoming ART Area Director: I have concerns with how i18n and unicode may interact with suite text strings and suite URIs. Particularly in the case of fetching remote content. I am also concerned about the potential IDNA issues with how UUIDs are constructed per Section 8.4.8.2. """ I believe this has been addressed as of: https://author-tools.ietf.org/iddiff?url1=draft-ietf-suit-manifest-26&url2=draft-ietf-suit-manifest-29&difftype=--html This comment is to make it clear, my position is currently no objection on this draft.
# Éric Vyncke, INT AD, comments for draft-ietf-suit-manifest-25 This is a rather superficial/high level ballot of mine (after the actual telechat) in the hope of getting enough ballots before the next IESG is seated. Thank you for the work put into this document. It is clearly written and pretty clear. I also like the fact that the text elements are i18n per section 8.4.4. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Russ Housley for the shepherd's write-up including the *brief* WG consensus *but it lacks* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Too complex for IoT When reading (even superficially) the whole document, I wonder whether a constrained device can realistically implement the full document (power, CPU, & memory constraints), are there proof of concept ? ## Section 1 Just curious about `a device to reason`, "to reason" may be a false friend with the French "raisonner", but it seems really weird to give some reasoning power (i.e., conscience) to a device... ## Section 4.1 Is lack of correct time also a limiting factor ? Or intermittent/unstable connection ? ## Section 6.2 Isn't the section title `Required Checks` in contradiction with the first sentence `The RECOMMENDED process is to verify` ? ## Section 8.4.8.1 Should "PEN" be expanded before first use ? ## Section 8.4.8.2 It is too late to raise a DISCUSS after the IESG telechat, but what is `DNS_PREFIX` ? I found definition neither in this I-D not in RFC 4122. Should it be `DNS_SUFFIX` BTW? `MCU` what is it ? I guess that it is not "MCU - Multipoint Control Unit (MCU)" per https://www.rfc-editor.org/materials/abbrev.expansion.txt # NITS (non-blocking / cosmetic) ## Wi-Fi or WiFi It seems that Wi-Fi is usually written with an hyphen. The RFC Editor will probably check anyway. ## E.g. Usually, "e.g." is followed by a comma.
(Section 5) the word choice is very confusing: "-- The manifest is structured from several key components: The Envelope (see Section 5.1) contains the Authentication Block, the Manifest, any Severable Elements, and any Integrated Payloads." The common sense reading of this is that the structure is recursive. The manifest contains an envelope, which contains a manifest, which contains an envelope. I think it should be "The metadata is structured"? Similarly, the hierarchy doesn't seem quite right here. The metadata contains a bunch of stuff, including the envelope, but the envelope actually contains all the other things. So perhaps the correct way to express it is that the envelope carries the metadata, which consists of items 2 through 5. Or maybe you mean something else, in which case this needs to be rewritten even more thoroughly. (Appendix C) s/Rational/Rationale.