[Gen-art] Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02

[Dan Romascanu <[e-mail]>]

Reviewer: Dan Romascanu
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sacm-nea-swima-patnc-02
Reviewer: Dan Romascanu
Review Date: 2018-02-18
IETF LC End Date: 2018-02-21
IESG Telechat date: 2018-02-22

Summary:

This is a solid and detailed specification, which extends PA-TNS with specific
attributes and message exchanges to allow endpoints to report their installed
software inventory information to a NEA server. It is Almost Ready from a
Gen-ART point of view, but there are some problems that I recommend to be
addressed before approval. The major problem is related to the complete lack of
information about how this specification fits into SACM, which SACM
requirements are addressed, how terminologies are made consistent and how
entities are mapped.

Major issues:

1. The document is labeled as a SACM document, but the text never explains the
connection with the SACM work, or the relation with the SACM architecture and
framework. There is no reference to SACM documents either. Section 9
'Relationship with other specifications' does not mention SACM either.

At a minimum, I believe that the document should:
- relate to the use cases of SACM - RFC 7632 (it does this for NEA, but this is
not sufficient for a SACM document) - ensure consistency, refer to the
terminology of SACM (draft-ietf-sacm-terminology), and provide a mapping
between the terms and entities defined in this document (e.g. SWIMA-PC,
SWIMA-PV, Evidence Record, Software Identifier) and the SACM terminology -
explain how the message exchanges fit in a SACM solution to meet the
requirements defined by RFC 8248. As an example, RFC 5792 has a detailed
appendix that evaluates the specifications against the requirements in RFC 5209
(NEA requirements).

2. The charter item that this WG falls under reads:

'- Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to
collect and deliver information about firmware, operating systems, and software
installed on an endpoint.'

The document covers in detail software inventory, but is mute about firmware
and operating systems. Arguably these two would fall under a broad
interpretation of 'software' but it would be better - at least - to provide an
explanation about these being covered and how, if not specific attributes
related to the types of software specified in the charter.

Minor issues:

1.Section 2.3:

I believe that the 'Interoperable' requirement is trivial and unnecessary in
the text of a Standards-Track document.

'   Interoperable:  This specification defines the protocol for how PCs
      and PVs can exchange and use software information to provide a NEA
      Server with information about an endpoint’s software inventory.
      Therefore, a key goal for this specification is ensuring that all
      SWIMA PCs and PVs, regardless of the vendor who created them, are
      able to interoperate in their performance of these duties.'

Interoperability is the obvious goal of any IETF standards-track document.
There is no need to repeat such an obvious statement.

2. Section 3.3

'   In the case that it is possible to do so, the SWIMA-PC SHOULD send
   its SWIMA Response attribute to the SWIMA-PV that requested it using
   exclusive delivery ...'

Assuming that 'it is possible to do so' means support for the mechanism, why is
this a SHOULD, and not a MUST?

Nits/editorial comments:

1. The Abstract section - quotation marks are open around the first document
name and never closed.