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

[Dan Romascanu <[e-mail]>]

Hi Charles,

Thank you for your response and for addressing my comments. I feel that
they are largely addressed by your proposed resolution. See also in-line.

Regards,

Dan


On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M. <[e-mail]>
wrote:

> 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."
>


This looks good. I would also suggest to add a sentence or paragraph
describing for short the relationship to SACM in the Introduction. As this
is a SACM WG document, some readers would probably expect to see this
relationship mentioned earlier than in Section 9.



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

I understand your point. Please continue the discussion with the SACM
terminology authors to try to reach consistency.




>
> -----
>
> 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."
>
>
Fine - this is exactly what I was looking for.


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

Makes sense.


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