Subject: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 8 Apr 2016 16:53:52 +0000

Out of the SACM session on Wednesday at IETF 95, Henk, Nancy, and I spent some time merging the text between the I-D IM [1] and the WG IM [2].  The result of that merger is captured in an updated version of the I-D IM [3] (note: the name of the draft was updated per Adam's request on the list [4]).
With that said, can the "Abstract" and "1. Introduction" of [3] replace the "Abstract" and "1. Introduction" of WG IM [2]?

Please review and provide any feedback by Monday March 18th.

Thanks,

Danny

[1] https://datatracker.ietf.org/doc/draft-cam-winget-sacm-information-model/
[2] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/
[3] https://datatracker.ietf.org/doc/draft-camwinget-sacm-information-model/
[4] http://www.ietf.org/mail-archive/web/sacm/current/msg03905.html

---

From: Adam Montville <[email-masked]>
Date: Fri, 8 Apr 2016 18:33:52 -0300

> On Apr 8, 2016, at 1:53 PM, Haynes, Dan <[email-masked]> wrote:
> 
> Out of the SACM session on Wednesday at IETF 95, Henk, Nancy, and I spent some time merging the text between the I-D IM [1] and the WG IM [2].  The result of that merger is captured in an updated version of the I-D IM [3] (note: the name of the draft was updated per Adam’s request on the list [4]).
> With that said, can the “Abstract” and “1. Introduction” of [3] replace the “Abstract” and “1. Introduction” of WG IM [2]?
> 

Given that today is April 8th, I think you meant April 18th.

> 
> Thanks,
> 
> Danny
> 
> [1] https://datatracker.ietf.org/doc/draft-cam-winget-sacm-information-model/ <https://datatracker.ietf.org/doc/draft-cam-winget-sacm-information-model/>
> [2] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/>
> [3] https://datatracker.ietf.org/doc/draft-camwinget-sacm-information-model/ <https://datatracker.ietf.org/doc/draft-camwinget-sacm-information-model/>
> [4] http://www.ietf.org/mail-archive/web/sacm/current/msg03905.html <http://www.ietf.org/mail-archive/web/sacm/current/msg03905.html>
> 
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: Adam Montville <[email-masked]>
Date: Fri, 8 Apr 2016 18:58:26 -0300

> With that said, can the “Abstract” and “1. Introduction” of [3] replace the “Abstract” and “1. Introduction” of WG IM [2]?

As contributor.

I think the abstract replacement is sane.  Some clarification on why we care only about data in motion and not as much about data at rest might be required.  I’m fine with focusing on data in motion, provided the expectation that any data at rest does not violate the relationships between information as established by the information model.  This might be handled well by slightly altering the last sentence in the first paragraph of the introduction to something like: “It is expected that information elements, and the relationships between them, expressed in this document are retained when fit into data models for data at rest.”  (Or something like that.)

The changes in the introduction seem significant, and I like the brevity of the proposed replacement.  It appears that you’ve dropped the “Problem Statement”, “Referring to An Endpoint”, and “Dealing with Uncertainty” subsections of the introduction.  Was this done because these topics are treated elsewhere?

It seems that you’ve also become more specific when talking about the tasks supported by the information model.  The current introduction speaks to things like “endpoint characterization” and the proposed introduction speaks to things like “target endpoint characterization”.  Was the qualifying word “target” chosen for a particular reason?

I ask, because in my mind “target endpoints” are the subject of an assessment process, but we need to deal with endpoints outside of such processes.  Configuration assessment or vulnerability assessment will have “target endpoints” to examine, but an endpoint management capability doesn’t really have “target endpoints”, because it is concerned with all endpoints (use of the qualifier “target” implies a subset of the whole).

My recommended change to the proposed introduction is to change “target endpoint” to “endpoint”.

Again, all of these comments are made with my contributor hat on.

Kind regards,

Adam

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 26 Apr 2016 20:21:28 +0000

Hi Adam,

A few comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Friday, April 08, 2016 5:58 PM
To: Haynes, Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

On Apr 8, 2016, at 1:53 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

As contributor.

[danny]: I see. I think  the main point with respect to data in motion vs. data at rest is that we primarily care about getting information from one SACM Component to another.  How it is stored in a Repository could be left for an implementer to decide.  With that said, you are right.  Things like relationships need to be retained somehow or at least re-constructible in the event that data including relationships must be provided in response to a query to the Repository.  Do you think it is worth calling out that the relationships can either be preserved directly in the data model or in some other way that allows them to be reconstructed at a later time (which may provide more flexibility)?  If both of these are covered by “retained” or this flexibility is not needed, I am fine with just using what you have proposed.

[danny]: When merging the text from the IMs, we were focused on making the WG IM as clear and concise as possible.  That is, what is the minimal text necessary to: (1) allow readers to understand what types of information we are trying to model, (2) what structures are available to model this information, and (3) the actual information elements that we think are necessary for SACM.  As a result, if the text didn’t seem critical to reaching this objective, we did not include it in the merged text.  Do you feel that this text is absolutely critical to include in the WG IM?  The main driver behind this is that the current WG IM is already very long :).

[danny]: We added the “target” qualifier because it was more specific to the tasks being supported by the IM and better aligned with the terminology document.

[danny]: Using the current definition of “target endpoint", wouldn’t an endpoint under the “endpoint management capability” be considered an “endpoint of interest” and as a result a “target endpoint”?
My recommended change to the proposed introduction is to change “target endpoint” to “endpoint”.

Kind regards,

Adam

---

From: Adam Montville <[email-masked]>
Date: Thu, 28 Apr 2016 18:39:41 -0500

A few? ;-)

Right back at you.

> On Apr 26, 2016, at 3:21 PM, Haynes, Dan <[email-masked]> wrote:
> 
> Hi Adam,
> 
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>]
> To: Haynes, Dan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Apr 8, 2016, at 1:53 PM, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
> 

This sounds like agreement, but I want to point out that the text I proposed was really intended to be a straw man.  If you want to stick with the text I’ve proposed I would not object, though others might.

> [danny]: When merging the text from the IMs, we were focused on making the WG IM as clear and concise as possible.  That is, what is the minimal text necessary to: (1) allow readers to understand w…

No I do not.  I was trying to understand the reasoning behind the change.

> [danny]: We added the “target” qualifier because it was more specific to the tasks being supported by the IM and better aligned with the terminology document.

This isn’t something I’m too hung up on, so if it makes sense to everyone else, that’s fine.  And see next comment.

> [danny]: Using the current definition of “target endpoint", wouldn’t an endpoint under the “endpoint management capability” be considered an “endpoint of interest” and as a result a “target endpoin…

I can see this perspective.  If I’m using the information model to organize characterization information and I’m just viewing that information, would it still be a “target” endpoint?  I suppose it’s the one I’m interested in, but I’m not sure it’s quite the same as “target” as used in the vulnerability assessment workflow.  Still, I’m not hung up on this, as long as we believe it’s clear to readers/implementers, etc.