A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest
draft-ietf-suit-manifest-29
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-11-07
|
29 | Murray Kucherawy | [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. -26 doesn't … [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. -26 doesn't solve the problem. Quoting IANA: === CBOR Tags have a field called “Data Item” that the IANA Considerations section still doesn’t populate. The designated expert had suggested using “map.” They just need to add a little text to the first two bullet points in Section 11. [seems to be fixed in -29] Also, I don’t understand why these new Reserved values have strings like “Unset Detection” and “Future Delegation” (not in brackets) in the “Reference” field. Would they want something like “Reserved (Unset Detection)” in the registry’“s Name” field instead? We definitely want to list a reference in the reference field, and would expect to list this document there. [not fixed as of -29] === 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. |
2024-11-07
|
29 | Murray Kucherawy | Ballot discuss text updated for Murray Kucherawy |
2024-11-07
|
29 | Brendan Moran | New version available: draft-ietf-suit-manifest-29.txt |
2024-11-07
|
29 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2024-11-07
|
29 | Brendan Moran | Uploaded new revision |
2024-11-04
|
28 | David Waltermire | Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable as a standards track document. Yes, the header calls for a Standards Track RFC. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This specification describes the format of a SUIT manifest. A manifest is a bundle of metadata about code and data obtained by a recipient, chiefly the firmware for an IoT device. The manifest tells the recipient where to find the code and data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and trusted invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than simply declaring the metadata. Working Group Summary: There is consensus for this document in the SUIT WG. Document Quality: Projects at the IETF Hackathon have informed this document. Personnel: Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd did a thorough review of the document during WG Last Call. All issues that were raised during WG Last Call have been resolved. Some IPR was disclosed at the beginning of 2023. That IPR disclosure was highlighted on the WG mailing list, and after several weeks no one has raise IPR concerns. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No concerns. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have explicitly stated that all known IPR has been disclosed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. See https://datatracker.ietf.org/ipr/5075/ and https://datatracker.ietf.org/ipr/5921/. No one raised any concerns regarding these IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus for this document in the SUIT WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few lines longer that 73 characters in the text. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No special reviews are needed. CBOR experts have looked at Appendix A. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Section 11 describes assignments in existing IANA registries and calls for the creation of new registries. Expert Review Instructions are provided for the new registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Section 11 calls for the creation of several new registries, and Section 11.8 provides Expert Review Instructions for the new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None are needed. |
2024-10-21
|
28 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-10-21
|
28 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-10-21
|
28 | Brendan Moran | New version available: draft-ietf-suit-manifest-28.txt |
2024-10-21
|
28 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2024-10-21
|
28 | Brendan Moran | Uploaded new revision |
2024-09-26
|
27 | (System) | Changed action holders to Hannes Tschofenig, Henk Birkholz, Brendan Moran, Øyvind Rønningstad, Koen Zandberg (IESG state changed) |
2024-09-26
|
27 | Roman Danyliw | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2024-09-26
|
27 | Paul Wouters | [Ballot discuss] [Updated for -27, removed one of two DISCUSS items resolved via a document update] A few minor easy to resolve DISCUSSes and comments: … [Ballot discuss] [Updated for -27, removed one of two DISCUSS items resolved via a document update] A few minor easy to resolve DISCUSSes and comments: 1) Registry Policy For each registry, values 0-255 are Standards Action and 256 or greater are Expert Review. Negative values -255 to 0 are Standards Action, and -256 and lower are Private Use. New entries to those registries need to provide a label, a name and a reference to a specification that describes the functionality. This sounds like "Specification Required" and not "Expert Review" ? |
2024-09-26
|
27 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2024-07-25
|
27 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-07-25
|
27 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-07-25
|
27 | Brendan Moran | New version available: draft-ietf-suit-manifest-27.txt |
2024-07-25
|
27 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2024-07-25
|
27 | Brendan Moran | Uploaded new revision |
2024-07-23
|
26 | Murray Kucherawy | [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. -26 doesn't … [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. -26 doesn't solve the problem. Quoting IANA: === CBOR Tags have a field called “Data Item” that the IANA Considerations section still doesn’t populate. The designated expert had suggested using “map.” They just need to add a little text to the first two bullet points in Section 11. Also, I don’t understand why these new Reserved values have strings like “Unset Detection” and “Future Delegation” (not in brackets) in the “Reference” field. Would they want something like “Reserved (Unset Detection)” in the registry’“s Name” field instead? We definitely want to list a reference in the reference field, and would expect to list this document there. === 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. |
2024-07-23
|
26 | Murray Kucherawy | [Ballot comment] 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 … [Ballot comment] 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? === From Orie Steele, incoming ART Area Director: In the abstract: This would be clearer if the first use of "IoT" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) Side note, is "Internet of Things Software Update (IoTSU)" a relevant / useful acronym here? In Section 4.2 consider defining "pull parser", prior to using the term. "The bootloader may add its own authentication, e.g. a Message Authentication Code (MAC), to the manifest in order to prevent further verifications." Why? In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference. Section 5.4 Comment: "Severable Elements", seems similar to selective disclosure and elision, you might want to relate your definitions to other industry terminology. Section 6.2 """ If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update, """ Under what circumstances can a recipient benefit from not verifying all components in the component set are specified by one update? (Why not MUST) Noting Section 8.4.3 and Section 8.4.4 have internationalization considerations. Section 8.4.8.10 '"" A URI Reference RFC3986 from which to fetch a resource, encoded as a text string. """ I believe this precludes URI's that contain unicode, you might consider borrowing some language from https://datatracker.ietf.org/doc/html/rfc9525#name-identifying-application-ser """ The information used to create the class-id condition (see {{uuid-identifiers) """ Reference typo. Section "8.4.5.1. SUIT_Component_Identifier" I'd prefer to see unicode considerations in this section. in Section 11.8 Are expired Internet drafts considered acceptable "stable references" for "standards track range of point assignment"... If not, please give concrete guidance to the experts regarding managing registrations of references that expire. """ When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. """ Sounds like you are asking for registries that are "Expert Review" not "Specification Required", please confirm after reading: https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 Extra text in each registry section, would make all this a lot clearer, as I noted in the beginning of my comments. In Section 11.9 Why not "application/suit-envelope+cose", under what circumstances can a suite envelope be transmitted as application/cose ? If there will never be other expressions that are not COSE, "application/suit-envelope" seems fine. |
2024-07-23
|
26 | Murray Kucherawy | Ballot comment and discuss text updated for Murray Kucherawy |
2024-07-23
|
26 | (System) | Changed action holders to Hannes Tschofenig, Henk Birkholz, Brendan Moran, Øyvind Rønningstad, Koen Zandberg (IESG state changed) |
2024-07-23
|
26 | Roman Danyliw | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2024-07-08
|
26 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-07-08
|
26 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-07-08
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2024-07-08
|
26 | Brendan Moran | New version available: draft-ietf-suit-manifest-26.txt |
2024-07-08
|
26 | Henk Birkholz | New version approved |
2024-07-08
|
26 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , Oyvind Ronningstad , suit-chairs@ietf.org |
2024-07-08
|
26 | Brendan Moran | Uploaded new revision |
2024-05-30
|
25 | Akira Tsukamoto | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Generator and Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations … Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Generator and Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/kentakayama/libcsuit (C implementation: Manifest Generator and Parser) related_implementations https://github.com/kentakayama/suit-manifest-generator (Python implementation 2: Manifest Generator) |
2024-04-04
|
25 | Barry Leiba | Request closed, assignment withdrawn: Cullen Jennings Last Call ARTART review |
2024-04-04
|
25 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events' |
2024-04-03
|
25 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-03-29
|
25 | Orie Steele | [Ballot comment] I support Murray's discuss. |
2024-03-29
|
25 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-03-04
|
25 | Martin Duke | [Ballot comment] (Section 5) the word choice is very confusing: "-- The manifest is structured from several key components: The Envelope (see Section 5.1) contains … [Ballot comment] (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. |
2024-03-04
|
25 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2024-03-04
|
25 | Éric Vyncke | [Ballot comment] # É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 … [Ballot comment] # É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. |
2024-03-04
|
25 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-02-29
|
25 | (System) | Changed action holders to Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Øyvind Rønningstad (IESG state changed) |
2024-02-29
|
25 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2024-02-29
|
25 | Murray Kucherawy | [Ballot comment] The shepherd writeup doesn't include the reason that PS is the right status here. === From Orie Steele, incoming ART Area Director: In … [Ballot comment] The shepherd writeup doesn't include the reason that PS is the right status here. === From Orie Steele, incoming ART Area Director: In the abstract: This would be clearer if the first use of "IoT" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) Side note, is "Internet of Things Software Update (IoTSU)" a relevant / useful acronym here? In Section 4.2 consider defining "pull parser", prior to using the term. "The bootloader may add its own authentication, e.g. a Message Authentication Code (MAC), to the manifest in order to prevent further verifications." Why? In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference. Section 5.4 Comment: "Severable Elements", seems similar to selective disclosure and elision, you might want to relate your definitions to other industry terminology. Section 6.2 """ If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update, """ Under what circumstances can a recipient benefit from not verifying all components in the component set are specified by one update? (Why not MUST) Noting Section 8.4.3 and Section 8.4.4 have internationalization considerations. Section 8.4.8.10 '"" A URI Reference RFC3986 from which to fetch a resource, encoded as a text string. """ I believe this precludes URI's that contain unicode, you might consider borrowing some language from https://datatracker.ietf.org/doc/html/rfc9525#name-identifying-application-ser """ The information used to create the class-id condition (see {{uuid-identifiers) """ Reference typo. Section "8.4.5.1. SUIT_Component_Identifier" I'd prefer to see unicode considerations in this section. in Section 11.8 Are expired Internet drafts considered acceptable "stable references" for "standards track range of point assignment"... If not, please give concrete guidance to the experts regarding managing registrations of references that expire. """ When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. """ Sounds like you are asking for registries that are "Expert Review" not "Specification Required", please confirm after reading: https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 Extra text in each registry section, would make all this a lot clearer, as I noted in the beginning of my comments. In Section 11.9 Why not "application/suit-envelope+cose", under what circumstances can a suite envelope be transmitted as application/cose ? If there will never be other expressions that are not COSE, "application/suit-envelope" seems fine. |
2024-02-29
|
25 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2024-02-29
|
25 | Murray Kucherawy | [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. I'm a … [Ballot discuss] Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. I'm a little puzzled by the use of "nint" as a placeholder in some of the registries. I don't understand what's going on there, and 8.4.8 (where it's apparently defined) didn't make it any clearer to me. Can I get a little clarification? === 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. |
2024-02-29
|
25 | Murray Kucherawy | [Ballot comment] In the abstract: This would be clearer if the first use of "IoT" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) … [Ballot comment] In the abstract: This would be clearer if the first use of "IoT" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) Side note, is "Internet of Things Software Update (IoTSU)" a relevant / useful acronym here? In Section 4.2 consider defining "pull parser", prior to using the term. "The bootloader may add its own authentication, e.g. a Message Authentication Code (MAC), to the manifest in order to prevent further verifications." Why? In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference. Section 5.4 Comment: "Severable Elements", seems similar to selective disclosure and elision, you might want to relate your definitions to other industry terminology. Section 6.2 """ If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update, """ Under what circumstances can a recipient benefit from not verifying all components in the component set are specified by one update? (Why not MUST) Noting Section 8.4.3 and Section 8.4.4 have internationalization considerations. Section 8.4.8.10 '"" A URI Reference RFC3986 from which to fetch a resource, encoded as a text string. """ I believe this precludes URI's that contain unicode, you might consider borrowing some language from https://datatracker.ietf.org/doc/html/rfc9525#name-identifying-application-ser """ The information used to create the class-id condition (see {{uuid-identifiers) """ Reference typo. Section "8.4.5.1. SUIT_Component_Identifier" I'd prefer to see unicode considerations in this section. in Section 11.8 Are expired Internet drafts considered acceptable "stable references" for "standards track range of point assignment"... If not, please give concrete guidance to the experts regarding managing registrations of references that expire. """ When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. """ Sounds like you are asking for registries that are "Expert Review" not "Specification Required", please confirm after reading: https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 Extra text in each registry section, would make all this a lot clearer, as I noted in the beginning of my comments. In Section 11.9 Why not "application/suit-envelope+cose", under what circumstances can a suite envelope be transmitted as application/cose ? If there will never be other expressions that are not COSE, "application/suit-envelope" seems fine. |
2024-02-29
|
25 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2024-02-29
|
25 | Paul Wouters | [Ballot discuss] A few minor easy to resolve DISCUSSes and comments: 1) Registry Policy For each registry, values 0-255 are Standards Action … [Ballot discuss] A few minor easy to resolve DISCUSSes and comments: 1) Registry Policy For each registry, values 0-255 are Standards Action and 256 or greater are Expert Review. Negative values -255 to 0 are Standards Action, and -256 and lower are Private Use. New entries to those registries need to provide a label, a name and a reference to a specification that describes the functionality. This sounds like "Specification Required" and not "Expert Review" ? 2) Severability question If a firmware has multiple severable parts, say PART1, TEXT1, PART2, where PART1 and PART2 are firmware blobs that cover say different parts of the hardware. They would be made severable. How can one detect that PART2 has been removed or replaced with a copy of TEXT1 if one also replaces the signature of the right part? eg would an attacker be able to get a firmware update partially installed, leaving in a potential security issue to exploit? |
2024-02-29
|
25 | Paul Wouters | [Ballot comment] 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 … [Ballot comment] 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". 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? I find this text a bit confusing: [...] make the following guarantees: One of: 1. A [...] AND 1. Where Might be the result of a misrender? Section 6.4 uses a term "statement" not defined before. It really sounds like "Command" to me, especially as one can "perform" a "statement". Section 6.7: that Commands MAY be executed in parallel or out of order. Should "or" be "and" ? 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? When the manifest processor encounters any of the following scenarios the parallel processing MUST pause until all issued commands have completed If the parallel processing pauses, wouldn't that pause the commands? I think perhaps you mean "the parallel processing MUST not issue new commands until all issued commands have completed" ? A Component MUST NOT be both a target of an operation and a source of data (for example, in Copy or Swap) in a Command Sequence where Strict Order is False. Wouldn't this also be true when Strict Order is True? Section 8.4.3 suit-reference-uri is a text string that encodes a URI What is a text string, esp. in relation to IDNs and non-ascii parts in a URI? Section 8.4.11 Should suit-command-custom be called suit-command-custom-n with n a negative integer? It might look from the command list there is only 1 custom command, but there can be multiple ones. Section 11.4 and 11.5 lists SUIT Commands/Parameters and shows a number of Reserved fields in the middle of these new allocations. IS there anything special with these values? Why are they reserved? Also, the text states value 0 is skipped on purpose to detect "unset", so should value 0 not be listed as Reserved? A technique to efficiently compress firmware images may be standardized in the future. Perhaps the compressing would be highly inefficient, to make decompressing highly efficient? Maybe just remove the word "efficiently" :) 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? NITS: see {#ovr-integrated}, Markdown misrender ? |
2024-02-29
|
25 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2024-02-28
|
25 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-02-28
|
25 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2024-02-27
|
25 | Amanda Baber | The expert has approved the CBOR Tag registrations, but noted that the "Data Item" field should read "map." Because IANA didn't receive a positive or … The expert has approved the CBOR Tag registrations, but noted that the "Data Item" field should read "map." Because IANA didn't receive a positive or negative response from the authors when our Last Call review identified the Data Item as "unsigned or negative integer," and the document doesn't explicitly mention the Data Item field, we need the authors to confirm that they agree that "map" should be used (and, when possible, include it in the IANA Considerations section). |
2024-02-27
|
25 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-02-26
|
25 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-02-26
|
25 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-02-26
|
25 | Tianran Zhou | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list. |
2024-02-25
|
25 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-02-21
|
25 | Cindy Morgan | Placed on agenda for telechat - 2024-02-29 |
2024-02-21
|
25 | Roman Danyliw | Ballot has been issued |
2024-02-21
|
25 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2024-02-21
|
25 | Roman Danyliw | Created "Approve" ballot |
2024-02-21
|
25 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-02-21
|
25 | Roman Danyliw | Ballot writeup was changed |
2024-02-21
|
25 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-02-20
|
25 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2024-02-20
|
25 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-suit-manifest-25. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-suit-manifest-25. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are ten actions which we must complete. First, a new category will be created on the IANA Matrix called Software Update for the Internet of Things (SUIT). This will be on the IANA Matrix at: https://www.iana.org/protocols Within this, IANA will create a registry group called SUIT Manifests with a reference of [ RFC-to-be ]. Second, in the registry group created in the first step above, a new registry will be created called SUIT Envelope Elements. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+------------ 2 Authentication Wrapper [ RFC-to-be; Section 8.3 ] 3 Manifest [ RFC-to-be; Section 8.4 ] 16 Payload Fetch [ RFC-to-be; Section 8.4.6 ] 17 Payload Installation [ RFC-to-be; Section 8.4.6 ] 23 Text Description [ RFC-to-be; Section 8.4.4 ] Third, in the registry group created in the first step above, a new registry will be created called SUIT Manifest Elements. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 1 Encoding Version [ RFC-to-be; Section 8.4.1 ] 2 Sequence Number [ RFC-to-be; Section 8.4.2 ] 3 Common Data [ RFC-to-be; Section 8.4.5 ] 4 Reference URI [ RFC-to-be; Section 8.4.3 ] 7 Image Validation [ RFC-to-be; Section 8.4.6 ] 8 Image Loading [ RFC-to-be; Section 8.4.6 ] 9 Image Invocation [ RFC-to-be; Section 8.4.6 ] 16 Payload Fetch [ RFC-to-be; Section 8.4.6 ] 17 Payload Installation [ RFC-to-be; Section 8.4.6 ] 23 Text Description [ RFC-to-be; Section 8.4.4 ] Fourth, in the registry group created in the first step above, a new registry will be created called SUIT Common Elements. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 2 Component Identifiers [ RFC-to-be; Section 8.4.5 ] 4 Common Command Sequence [ RFC-to-be; Section 8.4.5 ] Fifth, in the registry group created in the first step above, a new registry will be created called SUIT Commands. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 1 Vendor Identifier [ RFC-to-be; Section 8.4.9.1 ] 2 Class Identifier [ RFC-to-be; Section 8.4.9.1 ] 3 Image Match [ RFC-to-be; Section 8.4.9.2 ] 4 Reserved 5 Component Slot [ RFC-to-be; Section 8.4.9.4 ] 6 Check Content [ RFC-to-be; Section 8.4.9.3 ] 12 Set Component Index [ RFC-to-be; Section 8.4.10.1 ] 13 Reserved 14 Abort 15 Try Each [ RFC-to-be; Section 8.4.10.2 ] 16 Reserved 17 Reserved 18 Write Content [ RFC-to-be; Section 8.4.10.6 ] 19 Reserved 20 Override Parameters [ RFC-to-be; Section 8.4.10.3 ] 21 Fetch [ RFC-to-be; Section 8.4.10.4 ] 22 Copy [ RFC-to-be; Section 8.4.10.5 ] 23 Invoke [ RFC-to-be; Section 8.4.10.7 ] 24 Device Identifier [ RFC-to-be; Section 8.4.9.1 ] 25 Reserved 26 Reserved 27 Reserved 28 Reserved 29 Reserved 30 Reserved 31 Swap [ RFC-to-be; Section 8.4.10.9 ] 32 Run Sequence [ RFC-to-be; Section 8.4.10.8 ] 33 Reserved nint Custom Command [ RFC-to-be; Section 8.4.11 ] Sixth, in the registry group created in the first step above, a new registry will be created called SUIT Parameters. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 1 Vendor ID [ RFC-to-be; Section 8.4.8.3 ] 2 Class ID [ RFC-to-be; Section 8.4.8.4 ] 3 Image Digest [ RFC-to-be; Section 8.4.8.6 ] 4 Reserved 5 Component Slot [ RFC-to-be; Section 8.4.8.8 ] 12 Strict Order [ RFC-to-be; Section 8.4.8.14 ] 13 Soft Failure [ RFC-to-be; Section 8.4.8.15 ] 14 Image Size [ RFC-to-be; Section 8.4.8.7 ] 18 Content [ RFC-to-be; Section 8.4.8.9 ] 19 Reserved 20 Reserved 21 URI [ RFC-to-be; Section 8.4.8.10 ] 22 Source Component [ RFC-to-be; Section 8.4.8.11 ] 23 Invoke Args [ RFC-to-be; Section 8.4.8.12 ] 24 Device ID [ RFC-to-be; Section 8.4.8.5 ] 26 Reserved 27 Reserved 28 Reserved 29 Reserved 30 Reserved nint Custom [ RFC-to-be; Section 8.4.8.16 ] Seventh, in the registry group created in the first step above, a new registry will be created called SUIT Text Values. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 1 Manifest Description [ RFC-to-be; Section 8.4.4 ] 2 Update Description [ RFC-to-be; Section 8.4.4 ] 3 Manifest JSON Source [ RFC-to-be; Section 8.4.4 ] 4 Manifest YAML Source [ RFC-to-be; Section 8.4.4 ] nint Custom [ RFC-to-be; Section 8.4.4 ] Eighth, in the registry group created in the first step above, a new registry will be created calle SUIT Component Text Values. The registration policy for the new registry is: -256 or lower Private Use -255 to 255 Standards Action 256 or greater Expert Review There are initial registrations in the new registry as follows: Label Name Reference -----+-----+----------- 1 Vendor Name [ RFC-to-be; Section 8.4.4 ] 2 Model Name [ RFC-to-be; Section 8.4.4 ] 3 Vendor Domain [ RFC-to-be; Section 8.4.4 ] 4 Model Info [ RFC-to-be; Section 8.4.4 ] 5 Component Description [ RFC-to-be; Section 8.4.4 ] 6 Component Version [ RFC-to-be; Section 8.4.4 ] 7 Component Version Required [ RFC-to-be; Section 8.4.4 ] nint Custom [ RFC-to-be; Section 8.4.4 ] Ninth, in the application namespace of the Media Types registry located at: https://www.iana.org/assignments/media-types/ a single new registration will be made as follows: Name: suit-envelope Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Tenth, in the CBOR Tags registry in the Concise Binary Object Representation (CBOR) Tags registry group located at: https://www.iana.org/assignments/cbor-tags/ two new CBOR Tags will be registered as follows: Tag: [ TBD-at-Registration ] Data Item: Unsigned or negative integer Semantics: SUIT Envelope Reference: [ RFC-to-be ] Tag: [ TBD-at-Registration ] Data Item: Unsigned or negative integer Semantics: SUIT Manifest Reference: [ RFC-to-be ] IANA understands that the authors request values 107 and 1070 for the Tags for these registrations. As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-02-18
|
25 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list. |
2024-02-15
|
25 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2024-02-15
|
25 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2024-02-13
|
25 | Menachem Dodge | Assignment of request for Last Call review by OPSDIR to Menachem Dodge was rejected |
2024-02-12
|
25 | Barry Leiba | Request for Last Call review by ARTART is assigned to Cullen Jennings |
2024-02-12
|
25 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2024-02-08
|
25 | David Dong | IANA Experts State changed to Reviews assigned |
2024-02-08
|
25 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2024-02-07
|
25 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-02-07
|
25 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-02-21): From: The IESG To: IETF-Announce CC: David Waltermire , draft-ietf-suit-manifest@ietf.org, housley@vigilsec.com, rdd@cert.org, … The following Last Call announcement was sent out (ends 2024-02-21): From: The IESG To: IETF-Announce CC: David Waltermire , draft-ietf-suit-manifest@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, suit@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest) to Proposed Standard The IESG has received a request from the Software Updates for Internet of Things WG (suit) to consider the following document: - 'A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5921/ https://datatracker.ietf.org/ipr/5892/ https://datatracker.ietf.org/ipr/5075/ https://datatracker.ietf.org/ipr/3799/ https://datatracker.ietf.org/ipr/6008/ https://datatracker.ietf.org/ipr/5881/ The document contains these normative downward references. See RFC 3967 for additional information: rfc9019: A Firmware Update Architecture for Internet of Things (Informational - Internet Engineering Task Force (IETF)) rfc9124: A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices (Informational - Internet Engineering Task Force (IETF)) rfc9054: CBOR Object Signing and Encryption (COSE): Hash Algorithms (Informational - Internet Engineering Task Force (IETF)) |
2024-02-07
|
25 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-02-07
|
25 | Roman Danyliw | Last call was requested |
2024-02-07
|
25 | Roman Danyliw | Last call announcement was generated |
2024-02-07
|
25 | Roman Danyliw | Ballot approval text was generated |
2024-02-07
|
25 | Roman Danyliw | Ballot writeup was generated |
2024-02-07
|
25 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-02-05
|
25 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-02-05
|
25 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-02-05
|
25 | Brendan Moran | New version available: draft-ietf-suit-manifest-25.txt |
2024-02-05
|
25 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2024-02-05
|
25 | Brendan Moran | Uploaded new revision |
2023-11-04
|
24 | David Waltermire | Added to session: IETF-118: suit Tue-1600 |
2023-10-28
|
24 | Roman Danyliw | AD Review Follow-up on -24: https://mailarchive.ietf.org/arch/msg/suit/Vy44OGqjnN_58zA_2jnupPGTcOk/ |
2023-10-28
|
24 | (System) | Changed action holders to Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Øyvind Rønningstad (IESG state changed) |
2023-10-28
|
24 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2023-10-23
|
24 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-10-23
|
24 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-23
|
24 | Brendan Moran | New version available: draft-ietf-suit-manifest-24.txt |
2023-10-23
|
24 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2023-10-23
|
24 | Brendan Moran | Uploaded new revision |
2023-09-22
|
23 | Roman Danyliw | AD Review Follow-up on -23: https://mailarchive.ietf.org/arch/msg/suit/MJNk7-SBiRrEPRugmZKTlwkQ9jA/ |
2023-09-22
|
23 | (System) | Changed action holders to Hannes Tschofenig, Henk Birkholz, Brendan Moran, Øyvind Rønningstad, Koen Zandberg (IESG state changed) |
2023-09-22
|
23 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2023-09-11
|
23 | Dave Thaler | Added to session: interim-2023-suit-01 |
2023-09-10
|
23 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-09-10
|
23 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-09-10
|
23 | Hannes Tschofenig | New version available: draft-ietf-suit-manifest-23.txt |
2023-09-10
|
23 | Hannes Tschofenig | New version approved |
2023-09-05
|
23 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , Oyvind Ronningstad , suit-chairs@ietf.org |
2023-09-05
|
23 | Hannes Tschofenig | Uploaded new revision |
2023-07-24
|
22 | Dave Thaler | Added to session: IETF-117: suit Mon-2230 |
2023-05-24
|
22 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/suit/Ak_sFp1PaZcIRSol5Ge_xH2FN-w/ |
2023-05-24
|
22 | (System) | Changed action holders to Roman Danyliw, Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Øyvind Rønningstad (IESG state changed) |
2023-05-24
|
22 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2023-04-17
|
Jenny Bui | Posted related IPR disclosure Arm IP Ltd.'s Statement about IPR related to draft-ietf-suit-manifest | |
2023-03-14
|
22 | Russ Housley | Added to session: IETF-116: suit Thu-0400 |
2023-02-27
|
22 | Brendan Moran | New version available: draft-ietf-suit-manifest-22.txt |
2023-02-27
|
22 | Henk Birkholz | New version approved |
2023-02-27
|
22 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , Oyvind Ronningstad , suit-chairs@ietf.org |
2023-02-27
|
22 | Brendan Moran | Uploaded new revision |
2023-02-24
|
21 | Russ Housley | Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Yes, the header calls for a Standards Track RFC. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This specification describes the format of a SUIT manifest. A manifest is a bundle of metadata about code and data obtained by a recipient, chiefly the firmware for an IoT device. The manifest tells the recipient where to find the code and data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and trusted invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than simply declaring the metadata. Working Group Summary: There is consensus for this document in the SUIT WG. Document Quality: Projects at the IETF Hackathon have informed this document. Personnel: Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd did a thorough review of the document during WG Last Call. All issues that were raised during WG Last Call have been resolved. Some IPR was disclosed at the beginning of 2023. That IPR disclosure was highlighted on the WG mailing list, and after several weeks no one has raise IPR concerns. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No concerns. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have explicitly stated that all known IPR has been disclosed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. See https://datatracker.ietf.org/ipr/5075/ and https://datatracker.ietf.org/ipr/5921/. No one raised any concerns regarding these IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus for this document in the SUIT WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few lines longer that 73 characters in the text. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No special reviews are needed. CBOR experts have looked at Appendix A. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Section 11 describes assignments in existing IANA registries and calls for the creation of new registries. Expert Review Instructions are provided for the new registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Section 11 calls for the creation of several new registries, and Section 11.8 provides Expert Review Instructions for the new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None are needed. |
2023-02-24
|
21 | Russ Housley | Responsible AD changed to Roman Danyliw |
2023-02-24
|
21 | Russ Housley | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2023-02-24
|
21 | Russ Housley | IESG state changed to Publication Requested from I-D Exists |
2023-02-24
|
21 | Russ Housley | Document is now in IESG state Publication Requested |
2023-02-24
|
21 | Russ Housley | Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Shepherd Write-up for draft-ietf-suit-manifest-21 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Yes, the header calls for a Standards Track RFC. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This specification describes the format of a SUIT manifest. A manifest is a bundle of metadata about code and data obtained by a recipient, chiefly the firmware for an IoT device. The manifest tells the recipient where to find the code and data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and trusted invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than simply declaring the metadata. Working Group Summary: There is consensus for this document in the SUIT WG. Document Quality: Projects at the IETF Hackathon have informed this document. Personnel: Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd did a thorough review of the document during WG Last Call. All issues that were raised during WG Last Call have been resolved. Some IPR was disclosed at the beginning of 2023. That IPR disclosure was highlighted on the WG mailing list, and after several weeks no one has raise IPR concerns. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No concerns. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have explicitly stated that all known IPR has been disclosed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. See https://datatracker.ietf.org/ipr/5075/ and https://datatracker.ietf.org/ipr/5921/. No one raised any concerns regarding these IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus for this document in the SUIT WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few lines longer that 73 characters in the text. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No special reviews are needed. CBOR experts have looked at Appendix A. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Section 11 describes assignments in existing IANA registries and calls for the creation of new registries. Expert Review Instructions are provided for the new registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Section 11 calls for the creation of several new registries, and Section 11.8 provides Expert Review Instructions for the new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None are needed. |
2023-02-24
|
21 | Russ Housley | Notification list changed to David Waltermire <david.waltermire@nist.gov>, housley@vigilsec.com from David Waltermire <david.waltermire@nist.gov> because the document shepherd was set |
2023-02-24
|
21 | Russ Housley | Document shepherd changed to Russ Housley |
2023-01-18
|
Jenny Bui | Posted related IPR disclosure Nordic Semiconductor ASA's Statement about IPR related to draft-ietf-suit-manifest and draft-moran-suit-manifest | |
2023-01-09
|
Jenny Bui | Posted related IPR disclosure Nordic Semiconductor ASA's Statement about IPR related to draft-ietf-suit-manifest | |
2023-01-04
|
Jenny Bui | Posted related IPR disclosure Nordic Semiconductor ASA's Statement about IPR related to draft-ietf-suit-manifest | |
2022-11-09
|
21 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
2022-11-09
|
21 | Brendan Moran | New version available: draft-ietf-suit-manifest-21.txt |
2022-11-09
|
21 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2022-11-09
|
21 | Brendan Moran | Uploaded new revision |
2022-10-31
|
20 | Dave Thaler | Added to session: IETF-115: suit Wed-1300 |
2022-10-19
|
20 | Dave Thaler | Changed consensus to Yes from Unknown |
2022-10-19
|
20 | Dave Thaler | Intended Status changed to Proposed Standard from None |
2022-10-07
|
20 | Brendan Moran | New version available: draft-ietf-suit-manifest-20.txt |
2022-10-07
|
20 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2022-10-07
|
20 | Brendan Moran | Uploaded new revision |
2022-08-09
|
19 | Brendan Moran | New version available: draft-ietf-suit-manifest-19.txt |
2022-08-09
|
19 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2022-08-09
|
19 | Brendan Moran | Uploaded new revision |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python … Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Generator and Parser) |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (C implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python … Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (C implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (Python implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator ("Manifest Generator") related_implementations https://github.com/yuichitk/libcsuit/ to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (C implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C … Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator ("Manifest Generator") related_implementations https://github.com/yuichitk/libcsuit/ to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator (C implementation: Manifest Generator) related_implementations https://github.com/yuichitk/libcsuit/ (C implementation: Manifest Parser) |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator related_implementations https://github.com/yuichitk/libcsuit/ to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator ("Manifest Generator") related_implementations https://github.com/yuichitk/libcsuit/ |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator related_implementations https://github.com/yuichitk/libcsuit/ |
2022-07-27
|
18 | Dave Thaler | Changed document external resources from: github_repo https://github.com/suit-wg/manifest-spec to: github_repo https://github.com/suit-wg/manifest-spec related_implementations https://github.com/ARMmbed/suit-manifest-generator |
2022-07-13
|
18 | Russ Housley | Added to session: IETF-114: suit Thu-1600 |
2022-07-11
|
18 | Brendan Moran | New version available: draft-ietf-suit-manifest-18.txt |
2022-07-11
|
18 | Brendan Moran | New version accepted (logged-in submitter: Brendan Moran) |
2022-07-11
|
18 | Brendan Moran | Uploaded new revision |
2022-04-28
|
17 | Brendan Moran | New version available: draft-ietf-suit-manifest-17.txt |
2022-04-28
|
17 | (System) | New version approved |
2022-04-28
|
17 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , suit-chairs@ietf.org |
2022-04-28
|
17 | Brendan Moran | Uploaded new revision |
2022-04-28
|
16 | (System) | Document has expired |
2022-03-24
|
16 | Russ Housley | Added to session: IETF-113: suit Thu-1300 |
2021-10-25
|
16 | Brendan Moran | New version available: draft-ietf-suit-manifest-16.txt |
2021-10-25
|
16 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2021-10-25
|
16 | Brendan Moran | Uploaded new revision |
2021-10-25
|
15 | Brendan Moran | New version available: draft-ietf-suit-manifest-15.txt |
2021-10-25
|
15 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2021-10-25
|
15 | Brendan Moran | Uploaded new revision |
2021-09-01
|
Jenny Bui | Posted related IPR disclosure Arm IP Ltd.'s Statement about IPR related to draft-ietf-suit-manifest | |
2021-07-28
|
14 | Dave Thaler | Changed document external resources from: None to: github_repo https://github.com/suit-wg/manifest-spec |
2021-07-23
|
14 | Dave Thaler | Added to session: IETF-111: suit Fri-1200 |
2021-07-12
|
14 | Brendan Moran | New version available: draft-ietf-suit-manifest-14.txt |
2021-07-12
|
14 | (System) | New version approved |
2021-07-12
|
14 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , suit-chairs@ietf.org |
2021-07-12
|
14 | Brendan Moran | Uploaded new revision |
2021-05-25
|
13 | Brendan Moran | New version available: draft-ietf-suit-manifest-13.txt |
2021-05-25
|
13 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2021-05-25
|
13 | Brendan Moran | Uploaded new revision |
2021-05-23
|
12 | Russ Housley | Added to session: interim-2021-suit-01 |
2021-03-01
|
12 | Russ Housley | Added to session: IETF-110: suit Thu-1530 |
2021-02-22
|
12 | Brendan Moran | New version available: draft-ietf-suit-manifest-12.txt |
2021-02-22
|
12 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2021-02-22
|
12 | Brendan Moran | Uploaded new revision |
2020-12-08
|
11 | Brendan Moran | New version available: draft-ietf-suit-manifest-11.txt |
2020-12-08
|
11 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2020-12-08
|
11 | Brendan Moran | Uploaded new revision |
2020-11-05
|
10 | Dave Thaler | Added to session: IETF-109: suit Fri-1430 |
2020-11-02
|
10 | Brendan Moran | New version available: draft-ietf-suit-manifest-10.txt |
2020-11-02
|
10 | (System) | New version approved |
2020-11-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Koen Zandberg , Henk Birkholz , Hannes Tschofenig , Brendan Moran |
2020-11-02
|
10 | Brendan Moran | Uploaded new revision |
2020-07-14
|
09 | Russ Housley | Added to session: IETF-108: suit Fri-1100 |
2020-07-13
|
09 | Brendan Moran | New version available: draft-ietf-suit-manifest-09.txt |
2020-07-13
|
09 | (System) | New version approved |
2020-07-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: Henk Birkholz , suit-chairs@ietf.org, Koen Zandberg , Brendan Moran , Hannes Tschofenig |
2020-07-13
|
09 | Brendan Moran | Uploaded new revision |
2020-07-13
|
08 | Brendan Moran | New version available: draft-ietf-suit-manifest-08.txt |
2020-07-13
|
08 | (System) | New version approved |
2020-07-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: Koen Zandberg , Henk Birkholz , suit-chairs@ietf.org, Brendan Moran , Hannes Tschofenig |
2020-07-13
|
08 | Brendan Moran | Uploaded new revision |
2020-06-09
|
07 | Hannes Tschofenig | New version available: draft-ietf-suit-manifest-07.txt |
2020-06-09
|
07 | (System) | New version approved |
2020-06-09
|
07 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig , suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Koen Zandberg |
2020-06-09
|
07 | Hannes Tschofenig | Uploaded new revision |
2020-06-02
|
06 | Hannes Tschofenig | New version available: draft-ietf-suit-manifest-06.txt |
2020-06-02
|
06 | (System) | New version approved |
2020-06-02
|
06 | (System) | Request for posting confirmation emailed to previous authors: Koen Zandberg , suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2020-06-02
|
06 | Hannes Tschofenig | Uploaded new revision |
2020-05-27
|
05 | Hannes Tschofenig | New version available: draft-ietf-suit-manifest-05.txt |
2020-05-27
|
05 | (System) | New version approved |
2020-05-27
|
05 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig , suit-chairs@ietf.org, Brendan Moran , Koen Zandberg , Henk Birkholz |
2020-05-27
|
05 | Hannes Tschofenig | Uploaded new revision |
2020-05-26
|
04 | David Waltermire | Notification list changed to David Waltermire <david.waltermire@nist.gov> |
2020-05-26
|
04 | David Waltermire | Document shepherd changed to David Waltermire |
2020-03-09
|
04 | Brendan Moran | New version available: draft-ietf-suit-manifest-04.txt |
2020-03-09
|
04 | (System) | New version approved |
2020-03-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , suit-chairs@ietf.org |
2020-03-09
|
04 | Brendan Moran | Uploaded new revision |
2020-02-19
|
03 | Dave Thaler | Added to session: interim-2020-suit-01 |
2020-02-07
|
03 | Brendan Moran | New version available: draft-ietf-suit-manifest-03.txt |
2020-02-07
|
03 | (System) | New version approved |
2020-02-07
|
03 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Hannes Tschofenig , Brendan Moran |
2020-02-07
|
03 | Brendan Moran | Uploaded new revision |
2019-11-17
|
02 | David Waltermire | Added to session: IETF-106: suit Tue-1330 |
2019-11-04
|
02 | Brendan Moran | New version available: draft-ietf-suit-manifest-02.txt |
2019-11-04
|
02 | (System) | New version approved |
2019-11-04
|
02 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Hannes Tschofenig , Brendan Moran |
2019-11-04
|
02 | Brendan Moran | Uploaded new revision |
2019-10-29
|
01 | Brendan Moran | New version available: draft-ietf-suit-manifest-01.txt |
2019-10-29
|
01 | (System) | New version approved |
2019-10-28
|
01 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Hannes Tschofenig , Brendan Moran |
2019-10-28
|
01 | Brendan Moran | Uploaded new revision |
2019-10-21
|
00 | Dave Thaler | This document now replaces draft-moran-suit-manifest instead of None |
2019-10-21
|
00 | Brendan Moran | New version available: draft-ietf-suit-manifest-00.txt |
2019-10-21
|
00 | (System) | WG -00 approved |
2019-10-21
|
00 | Brendan Moran | Set submitter to "Brendan Moran ", replaces to draft-moran-suit-manifest and sent approval email to group chairs: suit-chairs@ietf.org |
2019-10-21
|
00 | Brendan Moran | Uploaded new revision |