[Suit] Re: AD comments on draft-ietf-suit-update-management

[Deb Cooley <[e-mail]>]

Inline w/ my original comments w/ [DC].  These are very minor - please make
a note of them for a future update.

I will put this draft into IETF Last Call. (huzzah!)

Deb

On Fri, Dec 12, 2025 at 4:55 AM Brendan Moran <[e-mail]> wrote:

> Hi Deb,
>
> Thank you for your review!
>
> I believe that we have now addressed all the comments that you have made
> on this draft.
>
> Best Regards,
> Brendan
>
> *From: *Deb Cooley <[e-mail]>
> *Date: *Friday, 31 October 2025 at 12:46
> *To: *[e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *[Suit] AD comments on draft-ietf-suit-update-management
>
> Apologies for sending these right before IETF 124.  The good news is that
> the submission tool reopens on 2 Nov.
>
> General:  If there is a SHOULD, then there needs to be a statement about
> when it might be ok to ignore.  If that statement is hard to determine,
> then why not MUST?  The other option is 'should' vice 'SHOULD'.  I'll try
> and point these out when I see them. Please see:
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
>
> Introduction, last paragraph:  Is there interoperability guidance for a
> device that either doesn't expect extensions, or does expect these
> extensions but they don't exist?
>
> Section 3.1, para 2:  'version SHOULD be encoded', what is the
> circumstance why this won't be done?  (or why not MUST?)  There is a later
> 'SHOULD NOT' where the addition of the build number will be ignored anyway,
> I'm not sure that we couldn't use 'should not' in this circumstance.
>
> Section 3.1, para 4:  SHOULD?  or MAY?  If SHOULD, then why would it be
> done differently?
>
> Section 3.2, para 2:  'SHOULD' or what?
>
> Section 3.3:  No formatting rules?  Does it have to be printable text?  Is
> there a length requirement?  the 'SHOULD' in this case should be obvious -
> otherwise a device operator will be confused.
>
[DC]  change 'no specific formatting rules'/ 'no additional specific
formatting rules'.

>
> Section 3.4, para 2, last sentence:  free text field with no specific
> formatting rules, seems like this could be used as an attack vector?  If
> the machine version is different from the text-version, which one is the
> authoritative one?
>
> [DC]   change 'no specific formatting rules'/ 'no additional specific
formatting rules'.

Section 4.4, last paragraph:  Isn't this true for all extensions?  Is this
> different from the statement in the Introduction?
>
> Section 4.4.1:
>  - SHOULD: what if they encoded versions aren't semantic versions?
>  - Move the examples to the end of the section.
>  - Add (RC) after '-1: Release Candidate'.
>
> Section 4.5:  ALL isn't a BCP 14 keyword.  How about:  'All wait events
> MUST be satisfied, before the Manifest Processor continues.'  Or just make
> it lower case.  Either will work.
>
> Section 4.5, last paragraph: 'suit-parameter-version-match' does not
> appear to be defined in this specification.  Perhaps it should be
> 'SUIT_Parameter_Version_Match'?  Or maybe just 'suit-parameter-version'?
>
> Section 4.6.1:  No rules for formatting?
>
> Section 5 and all subsections:  Some of these have a statement about being
> OPTIONAL to implement.  Are the other commands mandatory?
>
> Section 7:  The existence of unformatted text fields deserves a mention in
> this section.
>
[DC]  repeated word (Sections)


>
> Appendix A:  It is unusual for an appendix to have BCP 14 key words.  I
> would suggest changing 'MUST' to 'must'.  Lower case 'must' is still
> normative (see above on use of BCP 14 key words in appendices).
>
> Deb
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>