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

["Schmidt, Charles M." <[e-mail]>]

Hello,

Thanks a bunch for the comments. I'm glad that you feel that it looks like a solid contribution.

With regard to your feedback, I have developed wording to address both your major concerns and wanted to run it by you:

---
With regard to the lack of mention of SACM, I agree that it was an oversight not to mention it in the Relationship to Other Standards section. I propose adding the following paragraph at the end of that section:

"The NEA architecture is intended to support a broad range of activities and, as such, might be employed by other specifications. For example, requirement T-001 in the SACM Requirements document (RFC 8248) notes that NEA can support data collection from endpoints within the broader SACM architecture. (Other parts of the NEA architecture, which SWIMA uses, meet the other SACM data transport requirements.) In the SACM architecture, a SWIMA-PV corresponds to a “SACM Collector” and a SWIMA-PC is a “SACM Internal Collector”. In the SACM architecture, the SWIMA specification can support activities relating to software inventory collection. Specifically, SWIMA supports the SACM “Endpoint Posture Attribute Value Collection” use case (section 2.1.3 or RFC 7632) by describing a collection mechanism that enables event driven, scheduled, and ad-hoc data collection of software inventory information. SWIMA’s flexibility with regard to the format of inventory data records means that it is compatible with virtually any data format that implements SACM’s “Define, Publish, Query, and Retrieve Security Automation Data” (section 2.1.1 in RFC 7632). This is just one example of how SWIMA can support broader security solution standards. Note that, while SWIMA can support these SACM use cases, SWIMA has no dependencies upon the SACM architecture or any other context in which NEA might reasonably be applied."

I believe this addresses most of the specific points you wanted to include. I did not include a terminology mapping to "evidence record" and "software identifier" because the SACM Terminology definition of "attribute" is not internally consistent: it states "Attribute - Is a data element, as defined in [RFC5209], that is
atomic" and "equivalent to attribute-value-pairs". However, RFC 5209 (NEA) attributes are not atomic in nature, and will consist of many name-value pairs. (I'll send a separate comment to the SACM list regarding this.) As such, I'm not sure the terminology draft has a good parallel at this time and I stuck to the clearer mappings. 

-----

With regard to firmware and OS information, I added the following to the introduction:

" Note that while this specification focuses on “software inventory”, the mechanisms it describes could also be used to convey information about firmware and operating systems associated with an endpoint. The focus on software throughout this document should not be read as excluding the use of SWIMA for these other purposes."

---------

Do these additions adequately address your concerns?

Finally, with regard to the following question:

> 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?

In the NEA specification, the EXCL flag is only a recommendation to the Posture Broker Server/Client, and the recipient of a message with the flag set only "SHOULD" deliver it to a single party. (I realize that, in retrospect, my assertion that exclusive delivery "ensures" a behavior is incorrect and will fix that.) As such, saying that implementations MUST set a flag that only SHOULD be obeyed seems to be of questionable use, especially given that the specification clearly describes what to do if messages are not exclusively delivered.

Let me know if you disagree - I don't feel too strongly about this, but wanted to explain my thoughts.

----

Thanks again for the comments.

Charles

> -----Original Message-----
> From: Dan Romascanu [mailto:[e-mail]]
> Sent: Sunday, February 18, 2018 1:05 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
> 
> 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.
> 
>