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. <cmschm...@mitre.org> 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:droma...@gmail.com] > *Sent:* Wednesday, February 21, 2018 4:11 PM > *To:* Schmidt, Charles M. <cmschm...@mitre.org> > *Cc:* firstname.lastname@example.org; draft-ietf-sacm-nea-swima-patnc....@ietf.org; > i...@ietf.org; s...@ietf.org > *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. <cmschm...@mitre.org> > 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:droma...@gmail.com] > > Sent: Sunday, February 18, 2018 1:05 PM > > To: email@example.com > > Cc: draft-ietf-sacm-nea-swima-patnc....@ietf.org; i...@ietf.org; > > s...@ietf.org; droma...@gmail.com > > 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. > > > > > > >
_______________________________________________ Gen-art mailing list Genfirstname.lastname@example.org https://www.ietf.org/mailman/listinfo/gen-art