I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

The summary of the review is: Not Ready

Caveat: I found this document difficult.  I've not previously encountered an
"Informational Model" like this one, and I have not been following IoT.  If
these comments sound completely unhelpful then I may just not be the right
person to review this informational model.

I would prefer MAY, MUST, or SHOULD be used consistently instead of OPTIONAL
and RECOMMENDED.  Both are used here.

The draft is split into five lists, with 10 pages of Manifest Information
Element descriptions presumably forming the basis of the draft, but followed
by the bulk of the document as the Security Consideratios section.  I found
the organization confusing, too abstract, and somewhat circular.  In summary:

  o manifest elements satisfy one or more requirements
  o threats are mitigated by one or more requirements
  o security requirements (REQ.SEC) mitigate one or more threats
  o user stories are satisfied by one or more usability requirements
  o usability requirements (REQ.USE) satisfy user stories

pp.7 "the DNS name space ID"

This implies private DNS namespace may be a concern, and I'd like to
understand why and how, because this is based on Trust Anchors as described in
RFC6024.  What other DNS namespaces are under consideration?

pp.17, "This model uses the S.T.R.I.D.E. approach"

Microsoft's STRIDE Threat Model defines six types of threats: identity
spoofing, data tampering, repudiation, information disclosure, denial of
service, and elevation of privilege.  Why call out this particular approach?

There may be traffic analysis and fingerprinting concerns if the manifest is
not encrypted, specifically if the vendor IDs are sent unencrypted.

pp.10, "...that version MUST be specified"

It MUST be specified IF, but the element is OPTIONAL?

pp.10 Manifest Element: Expiration Time

Time is mentioned but no time format is specified.  Is synchronized time a
security requirement, and should specific time formats be specified?

pp.32 4.4.3, "Satisfied by USER_STORY.OVERRIDE (Section 4.4.3)"

Section 4.4.3 is circular (satisfies itself)

Derrell