Re: [Gen-art] New draft of SWIMA -03

[Dan Romascanu <[e-mail]>]

Hi Charles,

Thank you for updating me on the new version, for your responsiveness and
for addressing my comments. I believe that the document is now Ready from
the Gen-ART point of view. I suggest that you continue to work with the
authors of the SACM terminology document in order to reach consistency on
terminology, as discussed during our exchange of messages.

Regards,

Dan



On Wed, Feb 28, 2018 at 3:14 PM, Schmidt, Charles M. <[e-mail]>
wrote:

> Hi Dan,
>
> I wanted to send a quick note that a new draft of the SACM SWIMA
> specification has been uploaded. This draft includes the edits we
> discussed. Please let me know if you have any additional comments. Thanks
> again for the feedback - it really helped the specification.
>
> Thanks,
> Charles
>
> > -----Original Message-----
> > From: Dan Romascanu [mailto:[e-mail]]
> > Sent: Thursday, February 22, 2018 3:35 AM
> > To: Schmidt, Charles M. <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> patnc-02
> >
> > Hi Charles.
> >
> > This paragraph is very reasonable and informative for all audiences.
> >
> >
> > Thanks again.
> >
> >
> > Dan
> >
> >
> >
> > On Thu, Feb 22, 2018 at 12:23 AM, Schmidt, Charles M.
> > <[e-mail] <mailto:[e-mail]> > wrote:
> >
> >
> >       Hi Dan,
> >
> >
> >
> >       Thanks for your response. I agree on all points. I'll add the
> following
> > paragraph to the end of the introduction:
> >
> >
> >
> >       "Part of the motivation for the development of SWIMA was to
> > support the IETF’s Security Automation and Continuous Monitoring (SACM)
> > architecture. More details about SWIMA’s role in SACM appear in <xref
> > target=”Relationship”/>. However, SWIMA has no dependencies on any part
> > of SACM and is usable wherever the NEA architecture is employed."
> >
> >
> >
> >       Does this seem reasonable? (I agree that we need to address the
> > expectation that people will have to see SACM mentioned in a SACM WG
> > document, but I also want to make very sure that people don't see SWIMA
> as
> > only being applicable in that context.)
> >
> >
> >
> >       Thanks,
> >
> >       Charles
> >
> >
> >
> >       From: Dan Romascanu [mailto:[e-mail]
> > <mailto:[e-mail]> ]
> >       Sent: Wednesday, February 21, 2018 4:11 PM
> >       To: Schmidt, Charles M. <[e-mail]
> > <mailto:[e-mail]> >
> >       Cc: [e-mail] <mailto:[e-mail]> ;
> draft-ietf-sacm-nea-
> > [e-mail] <mailto:draft-ietf-sacm-nea-swima-
> > [e-mail]> ; [e-mail] <mailto:[e-mail]> ;
> [e-mail]
> > <mailto:[e-mail]>
> >       Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> > patnc-02
> >
> >
> >
> >       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] <mailto:[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]
> > <mailto:[e-mail]> ]
> >               > Sent: Sunday, February 18, 2018 1:05 PM
> >               > To: [e-mail] <mailto:[e-mail]>
> >               > Cc: [e-mail]
> > <mailto:[e-mail]> ; [e-mail]
> > <mailto:[e-mail]> ;
> >               > [e-mail] <mailto:[e-mail]> ;
> > [e-mail] <mailto:[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
> > <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
> > <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.
> >               >
> >               >
> >
> >
> >
>
>