Telechat Review of draft-ietf-sacm-nea-swima-patnc-02
review-ietf-sacm-nea-swima-patnc-02-genart-telechat-romascanu-2018-02-18-00
Review
review-ietf-sacm-nea-swima-patnc-02-genart-telechat-romascanu-2018-02-18
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.