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

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

Hi Kathleen,

I have addressed Dan's, Eric's, and your comments in my current draft and can make the IANA updates quickly. I won't be able to get the comments received late yesterday (Benjamin, Ben, Adam, and Alexey) addressed before 10:00. (Alissa's comments were addressed with Dan's.)

Would you like me to send the draft with those updates, or hold off until I can get the last flurry of comments resolved?

Also, would it be possible for me to listen in on the telechat? I know it is happening today, but haven't been able to find any information about when (although I'm guessing 10:00) or how to participate.

Thanks a bunch,
Charles

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[e-mail]]
> Sent: Thursday, February 22, 2018 6:40 AM
> To: Dan Romascanu <[e-mail]>
> Cc: Schmidt, Charles M. <[e-mail]>; draft-ietf-sacm-nea-
> [e-mail]
> Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
> 
> Charles,
> 
> If your running draft addresses all comments, could you please post it before
> 10AM?  I may be able to approve it on the telechat.
> 
> Thank you for all your work on this and addressing the comments received.
> 
> Best regards,
> Kathleen
> 
> Sent from my mobile device
> 
> On Feb 22, 2018, at 3:35 AM, Dan Romascanu <[e-mail]
> <mailto:[e-mail]> > wrote:
> 
> 
> 
> 	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-
> [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.
> 			>
> 			>
> 
> 
>