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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
