I agree with the DISCUSS about the intended status.

It does appear that this document got both a media-type and CBOR review.

Thanks to the authors and the WG for their work on this document and for the updates to clear my previous DISCUSS position.

Overall, the document seems in good shape. I think some rearrangement of the IANA Considerations would make them easier to parse -- add links to the registries that already exist, move the request to create new registries into the sections with their definitions, etc. The top-level discussion in Section 9 should be either instructions that apply to many of the registries listed (e.g. creation of a group) or a preview of what is done in detail in the subsections (ideally with forward-references).

I support the DISCUSS about intended status, but that seems like a simple fix.

Hi Brendan and Henk,

Thank you for the changes made in -16 [1]. These address my DISCUSS/COMMENT points [2]. 

One very minor comment, it seems this one didn't make it to the published version per [3]:

----
>
> # Consistent patterns for reason code:
>
> CURRENT:
>    *  suit-report-reason-component-unauthorised: The manifest declared a
>       component that is not accessible by the signer.
>
>    *  suit-report-reason-parameter-unsupported: The manifest used a
>       parameter that does not exist.
>
>    *  suit-report-severing-unsupported: The manifest uses severable
>       fields but the Manifest Processor doesn't support them.
>
> Any reason the code=9/suit-report-severing-unsupported does not have the same
> pattern as other reasons?

Fixed.
---------------

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-suit-report-15&url2=draft-ietf-suit-report-16&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/suit/1OO8p0hH5hS_gokAvGCpu64lqmk/

[3] https://mailarchive.ietf.org/arch/msg/suit/7b3JyoLek7B8BM6SVWbLiVsk6to/

I agree with the missing normative references Med pointed out, and would also like to see the discussion on Informational vs Proposed Standard that Ketan raised.

Thank you to Behcet Sarikaya for the GENART review.

** Section 9.2
   *  Specifications are required for the standards track range of point
      assignment.  Specifications should exist for all other ranges, but
      early assignment before a specification is available is considered
      to be permissible.  When specifications are not provided, the
      description provided needs to have sufficient information to
      identify what the point is being used for.
   *  Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      standards track documents does not mean that a standards track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, the size of device it will be
      used on, and the number of code points left that encode to that
      size.

There are three ranges with different allocation policies, but this technically only applies to one of the (the specification required range)
   *  -256 to 255: Standards Action
   *  -65536 to 257, 256 to 65535: Specification Required
   *  -4294967296 to -65537, 65536 to 4294967295: First Come, First
      Served

-- standards action doesn’t require review by the designated expert

-- FCFS does not involve any substantive review of the request (and doesn’t involve an expert)

** Section 9.5  
-- What is the role of the 5th column in the registry? It is unlabeled and only value 99 has a value?

-- what does “suit-reference” as the Reference for value 99 mean?

** Section 9.5, 9.6, 9.7 and 9.8.  Should the reference value noted for the Reference column in these registries be more than a section number? Shouldn’t it be a section number and the future RFC?  How will reference to just a section without no RFC be easily discoverable?