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

Dan, thank you for your review. I don’t think your major issues are quite DISCUSS-worthy, but I’ve called them out in my No Objection ballot.

Alissa

> On Feb 18, 2018, at 11:04 AM, Dan Romascanu <dromasca@gmail.com> wrote:
> 
> 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.
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art