Subject: Re: [sacm] Updating DM-001

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 13 Sep 2016 04:46:06 +0000

Hi all,

I’d like to get better consensus on the update, so given the thread, I
think perhaps an updated wording could be:

----START----
Each data model element MUST be associated with at least one SACM
information model element; data model elements MAY also map
to more than one SACM information model element.  For example, two SACM
information model elements could be mapped to a single SACM data model
element. A SACM compliant data model can also define elements that do not
directly correspond to any item in the SACM information model.
----END——

This keeps the terminology consistant with the rest of the requirements…

Thoughts?
	Nancy

On 8/1/16, 12:40 PM, "John Strassner" <[email-masked]> wrote:

>Hi Adam,
>
>I don't quite follow your third point.
>
>> Not "fit into", but rather, "derived from". The typical example is
>> abstract classes (which by definition cannot be instantiated, so
>> their contents have to go somewhere, right :-) ) - this is called
>> "flattening the hierarchy". Other examples parallel the
>> normalization/denormalization processes in relational calculus (the
>> IM normalizes objects and their relationships, but the DM may not).
>
>
>Let’s look at SWID as one example.  Our IM will say something about
>software identification.  SWID exists.  Then, SWID isn’t really “derived
>from” our IM.  Instead, our IM is created and we are going to evaluate how
>SWID satisfies (i.e. fits into) the IM.  This is just one example.  The
>idea behind collection is, and has been, that we would leverage existing
>data models wherever possible, and in my mind that means we’re looking
>more
>at how we evaluate a given data model for SACM IM fitness rather than how
>we build one to match.
>
><jcs>
>I guess you are reacting to "derived from", correct? In your example,
>the IM gives the structure in which the SWID is interpreted. So, point
>taken. The original question, however, was the assertion:
>
>>> 3.  If it makes sense that a single data element can map from two IM
>>> elements, then this is a fault in the IM and should be fixed there.
>>> That statement does not make sense to me.
>
>That is why I used "derived from", because it mapped particularly well
>into answering the above question.
>
>So hopefully we have resolved that yes, you could flatten the IM and
>have multiple IM **elements** map into a single DM **element**.
>
>regards,
>John
>
>
>
>On Fri, Jul 29, 2016 at 10:01 AM, Adam Montville
><[email-masked]
>> wrote:
>
>>
>> > On Jul 28, 2016, at 5:20 PM, John Strassner <
>> [email-masked]> wrote:
>> >
>> > Hi Adam,
>> >
>> >>> The one currently in the document both reads more smoothly and is
>>far
>> >>> more understandable to me that what is below.
>> >>>
>> >>> 1.  what the blazes is an artifact - this is a new concept that I
>> >>> don't understand
>> >> I think “artifact” in the proposed text is “element” in the existing
>> >> text, so I would also want to see that cleaned up.
>> >
>> > The problem is that "model element" has connotations in the modeling
>> > world that we don't (yet) support. I think that artifact (as in
>> > **software artifact**) is more clear.
>>
>> I’m personally indifferent, but I would like continuity within the
>>draft.
>> We determined that DM-001 would be the only text we touch, so if
>>“element”
>> is used elsewhere in the draft, I would have to say we should use it
>>here

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 13 Sep 2016 13:47:12 +0000

Hi Nancy,

I included this topic in the IM Update slides for today so we will definitely get to discuss it. For the slides, I included the following text which I came up with based on feedback in this thread.

----START----

Each data model element that is derived from the SACM Information Model MUST be associated with at least one SACM Information Model element and MAY be associated with more than one SACM Information Model element. A SACM data model MAY include additional data model elements that are not associated with any SACM Information Model elements. For example, two SACM Information Model elements from the SACM Information Model could be mapped to a single SACM data model element. As another example, a SACM data model element does not need to directly correspond to any item in the SACM Information Model element.

----END----

Regarding your proposed text, I am concerned with the first sentence which says “Each data model element MUST be associated with at least one SACM information model element;”. I think this creates the same problem we were trying to address in the rewrite. Furthermore, it seems to contradict (at least to me) with the last sentence which says “A SACM compliant data model can also define elements that do not directly correspond to any item in the SACM information model.”. Of course, I could be misinterpreting something. We can talk more during the call today.

Thanks,

Danny

> -----Original Message-----

> From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]]

> Sent: Tuesday, September 13, 2016 12:46 AM

> To: John Strassner <[email-masked]>; Adam Montville

> <[email-masked]>

> Cc: Jim Schaad <[email-masked]>; Haynes, Dan <[email-masked]>;

> [email-masked]; [email-masked]

> Subject: Re: [sacm] Updating DM-001

> I’d like to get better consensus on the update, so given the thread, I think

> perhaps an updated wording could be:

> information model element; data model elements MAY also map to more than

> one SACM information model element.  For example, two SACM information

> model elements could be mapped to a single SACM data model element. A

> SACM compliant data model can also define elements that do not directly

> correspond to any item in the SACM information model.

> On 8/1/16, 12:40 PM, "John Strassner" <[email-masked]<mailto:[email-masked]>> wrote:

> >software identification.  SWID exists.  Then, SWID isn’t really

> >“derived from” our IM.  Instead, our IM is created and we are going to

> >evaluate how SWID satisfies (i.e. fits into) the IM.  This is just one

> >example.  The idea behind collection is, and has been, that we would

> >leverage existing data models wherever possible, and in my mind that

> >means we’re looking more at how we evaluate a given data model for SACM

> >IM fitness rather than how we build one to match.

> >> [email-masked]<mailto:[email-masked]>> wrote:

> >> >> I think “artifact” in the proposed text is “element” in the

> >> >> existing text, so I would also want to see that cleaned up.

> >> > The problem is that "model element" has connotations in the

> >> > modeling world that we don't (yet) support. I think that artifact

> >> > (as in **software artifact**) is more clear.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 13 Sep 2016 14:20:46 +0000

This text seems reasonable to me.

Thanks,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Nancy Cam-
> Winget (ncamwing)
> Cc: Jim Schaad <[email-masked]>; Haynes, Dan
> <[email-masked]>; [email-masked]; draft-ietf-sacm-
> [email-masked]
> information model element; data model elements MAY also map to more
> than one SACM information model element.  For example, two SACM
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 13 Sep 2016 16:07:46 +0000

Hi Danny,

I will be late for the interim as I am triply booked for the same timeslot, but yes we need to discuss so I can rev the draft in fhs

However, the updated paragraph is still confusing to me as the “For example…..” is really about describing how a data model element can map to more than one information model element but the previous sentence goes to state that extensions can be made to a data model that are not part of the SACM IM.  Which is why I changed that ordering.

I’m not sure why you think my split of your first sentence into 2 clauses is confusing….as it is basically saying the same thing?

Nancy

From: "Haynes, Dan" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 13, 2016 at 6:47 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Strassner <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sacm] Updating DM-001

Hi Nancy,

----END----

Thanks,

Danny

> To: John Strassner <[email-masked]<mailto:[email-masked]>>; Adam Montville

> <[email-masked]<mailto:[email-masked]>>

> Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Haynes, Dan <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> ><[email-masked]<mailto:[email-masked]>

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 09:25:08 -0700

Hi all,

my voice is shot (much to the relief of my wife!), not sure if it makes
sense for me to attend. However, regarding the above discussion, I believe
the confusion is because the first sentence is talking about a 1..n
relationship between an unspecified data model element to the SACM info
model element, whereas the second sentence introduces the term **data
model**, and says that a SACM data model MAY include additional data model
elements.

IMHO, the way to clean this up is to talk consistently about SACM info
models and SACM data models, and elements of each. So how about:

A SACM Information Model consists of a set of SACM Information Model
elements. One or more SACM Data Models may be derived from the SACM
Information Model, where each derived SACM Data Model consists of a set of
SACM Data Model elements. In this derivation, a SACM Data Model element MAY
be derived from one or more SACM Information Model elements. In addition, a
SACM Data Model MAY include additional Data Model elements that are not
associated with any SACM Information Model elements. For example, two SACM
Information Model elements could be mapped to a single SACM Data Model
element. As another example, a SACM Data Model element does not need to
directly correspond to any SACM Information Model element.

regards,
John

On Tue, Sep 13, 2016 at 9:07 AM, Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> Hi Danny,
>
> I will be late for the interim as I am triply booked for the same
> timeslot, but yes we need to discuss so I can rev the draft in fhs
>
> However, the updated paragraph is still confusing to me as the “For
> example…..” is really about describing how a data model element can map to
> more than one information model element but the previous sentence goes to
> state that extensions can be made to a data model that are not part of the
> SACM IM.  Which is why I changed that ordering.
>
> I’m not sure why you think my split of your first sentence into 2 clauses
> is confusing….as it is basically saying the same thing?
>
>
> Nancy
>
> From: "Haynes, Dan" <[email-masked]>
> To: "[email-masked]" <[email-masked]>, John Strassner <
> [email-masked]>, Adam Montville <[email-masked]>
> Cc: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <draft-ietf-sacm-requirements@
> ietf.org>
> I included this topic in the IM Update slides for today so we will
> definitely get to discuss it. For the slides, I included the following text
> which I came up with based on feedback in this thread.
>
>
>
> ----START----
>
> Each data model element that is derived from the SACM Information Model
> MUST be associated with at least one SACM Information Model element and MAY
> be associated with more than one SACM Information Model element. A SACM
> data model MAY include additional data model elements that are not
> associated with any SACM Information Model elements. For example, two SACM
> Information Model elements from the SACM Information Model could be
> mapped to a single SACM data model element. As another example, a SACM data
> model element does not need to directly correspond to any item in the
> SACM Information Model *element*.
>
> ----END----
>
>
>
> Regarding your proposed text, I am concerned with the first sentence which
> says “Each data model element MUST be associated with at least one SACM
> information model element;”. I think this creates the same problem we were
> trying to address in the rewrite. Furthermore, it seems to contradict (at
> least to me) with the last sentence which says “A SACM compliant data model
> can also define elements that do not directly correspond to any item in the
> SACM information model.”. Of course, I could be misinterpreting something.
> We can talk more during the call today.
>
>
>
> Thanks,
>
> Danny
>
>
>
> > From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]
> <[email-masked]>]
>
> > Cc: Jim Schaad <[email-masked]>; Haynes, Dan <[email-masked]
> >;
>
> think

-- 
regards,
John

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 13 Sep 2016 18:55:05 +0000

Hi John et al,

We discussed this in the virtual interim today and decided that we need to close on this one soon, so we can continue discussions for the next 48hrs at which point I will update based on results of this thread.

That said,  John….I’m not sure if your "where each derived SACM Data Model consists of a set of SACM Data Model elements” the latter was meant to be “SACM Information Model elements”?  Note that we haven’t defined a SACM Data Model yet….and I think there is discord to whether there is 1 unifying SACM Data Model or if a SACM Data Model can be a “subset” of a SACM Information Model.  The original text intended there to only be one SACM Data Model that encompassed the information needed to be collected and assessed.

By “unifying”, I do think we will need to demonstrate how implementations can interoperate and I think it can only be achieved in one of 2 ways:

  1.  define a single SACM Data Model:  a data model that encompasses all of the Information Model elements to allow for posture collection results, acquired posture configuration and assessment results that can be transported across SACM components.  How posture is collected, configured or assessed imho is not in scope for the SACM Data Model….
  2.  Define a set of data models that partially address pieces of the SACM Information Model  (and can be construed as “SACM IM Compliant”?), as was mentioned in the interim today, there may be a data model that is based on NEA or OVAL, etc….but are targeted to a specific task.

To show interoperability:

  *   For Option 1: should be more straightforward as the draft would specify what is Mandatory to Implement (MTI) from the SACM Data Model.
  *   For Option 2:  the WG can define a “minimal” set of these data models that MUST be supported to allow for interoperability; also, within each data model they each also have to specify the MTI elements.   In addition, the WG has to define how these data models work together (as there may be a specific expected flow or usage for them?).

OK, that said…..your proposed text ambiguates the notion of 1 SACM DM and the association of SACM IM elements

Here’s a new proposal:
A SACM Information Model consists of a set of SACM Information Model elements.  A SACM Data Models MUST be derived from the SACM Information Model.
A SACM Data Model consists of a set of SACM Data Model elements. In this derivation, a SACM Data Model element MAY map to one or more SACM Information Model elements. In addition, a SACM Data Model MAY include additional Data Model elements that are not associated with any SACM Information Model elements.

Nancy (and Henk)

From: John Strassner <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 13, 2016 at 9:25 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: "Haynes, Dan" <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>, Jim Schaad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Updating DM-001

Hi all,

my voice is shot (much to the relief of my wife!), not sure if it makes sense for me to attend. However, regarding the above discussion, I believe the confusion is because the first sentence is talking about a 1..n relationship between an unspecified data model element to the SACM info model element, whereas the second sentence introduces the term **data model**, and says that a SACM data model MAY include additional data model elements.

IMHO, the way to clean this up is to talk consistently about SACM info models and SACM data models, and elements of each. So how about:

A SACM Information Model consists of a set of SACM Information Model elements. One or more SACM Data Models may be derived from the SACM Information Model, where each derived SACM Data Model consists of a set of SACM Data Model elements. In this derivation, a SACM Data Model element MAY be derived from one or more SACM Information Model elements. In addition, a SACM Data Model MAY include additional Data Model elements that are not associated with any SACM Information Model elements. For example, two SACM Information Model elements could be mapped to a single SACM Data Model element. As another example, a SACM Data Model element does not need to directly correspond to any SACM Information Model element.

regards,
John

On Tue, Sep 13, 2016 at 9:07 AM, Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Danny,

Nancy

Hi Nancy,

----END----

Thanks,

Danny

--
regards,
John

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 13 Sep 2016 19:58:15 +0000

I believe we will minimally need:

1)  a data model for interacting with repositories of security automation guidance (also a charter item).
2) one or more data models for collecting data from endpoints (
3) at minimum a single data model to allow collected data to be provided to other SACM components.

Given this view of the SACM world, we need to consider Nancy’s option 2.

Here’s is a modified proposal, based on Nancy’s text to clarify option 2:

A SACM Information Model consists of a set of SACM Information Model elements.  SACM needs to define one or more data models to support different protocol exchanges that support assessment workflows. A SACM Data Models MUST be derived from the SACM Information Model.
A SACM Data Model consists of a set of SACM Data Model elements. In this derivation, a SACM Data Model element MAY map to one or more SACM Information Model elements. In addition, a SACM Data Model MAY include additional Data Model elements that are not associated with any SACM Information Model elements.

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, September 13, 2016 2:55 PM
To: John Strassner <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]; Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; [email-masked]
Subject: Re: [sacm] Updating DM-001

Hi John et al,

Here’s a new proposal:

Nancy (and Henk)

Hi all,

regards,
John

Nancy

Hi Nancy,

----END----

Thanks,

Danny

--
regards,
John

---

From: Ira McDonald <[email-masked]>
Date: Tue, 13 Sep 2016 16:42:50 -0400

Hi Dave,

+1

Cheers,
- Ira

On Tue, Sep 13, 2016 at 3:58 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> elements.  *SACM needs to define one or more data models to support
> different protocol exchanges that support assessment workflows.* A SACM
> Data Models MUST be derived from the SACM Information Model.
>
> A SACM Data Model consists of a set of SACM Data Model elements. In this
> derivation, a SACM Data Model element MAY map to one or more SACM
> Information Model elements. In addition, a SACM Data Model MAY include
> additional Data Model elements that are not associated with any SACM
> Information Model elements.
>
>
>
> Thanks,
>
> Dave
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Nancy
> Cam-Winget (ncamwing)
> *Sent:* Tuesday, September 13, 2016 2:55 PM
> *To:* John Strassner <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; draft-ietf-sacm-requirements@
> ietf.org; Haynes, Dan <[email-masked]>; Adam Montville <
> [email-masked]>; [email-masked]
>
> *Subject:* Re: [sacm] Updating DM-001
>
>
>
> Hi John et al,
>
>
>
> We discussed this in the virtual interim today and decided that we need to
> close on this one soon, so we can continue discussions for the next 48hrs
> at which point I will update based on results of this thread.
>
>
>
> That said,  John….I’m not sure if your "where each derived SACM Data Model
> consists of a set of SACM Data Model elements” the latter was meant to be
> “SACM Information Model elements”?  Note that we haven’t defined a SACM
> Data Model yet….and I think there is discord to whether there is 1 unifying
> SACM Data Model or if a SACM Data Model can be a “subset” of a SACM
> Information Model.  The original text intended there to only be one SACM
> Data Model that encompassed the information needed to be collected and
> assessed.
>
>
>
> By “unifying”, I do think we will need to demonstrate how implementations
> can interoperate and I think it can only be achieved in one of 2 ways:
>
>    1. define a single SACM Data Model:  a data model that encompasses all
>    of the Information Model elements to allow for posture collection results,
>    acquired posture configuration and assessment results that can be
>    transported across SACM components.  How posture is collected, configured
>    or assessed imho is not in scope for the SACM Data Model….
>    2. Define a set of data models that partially address pieces of the
>    SACM Information Model  (and can be construed as “SACM IM Compliant”?), as
>    was mentioned in the interim today, there may be a data model that is based
>    on NEA or OVAL, etc….but are targeted to a specific task.
>
>    - For Option 1: should be more straightforward as the draft would
>    specify what is Mandatory to Implement (MTI) from the SACM Data Model.
>    - For Option 2:  the WG can define a “minimal” set of these data
>    models that MUST be supported to allow for interoperability; also, within
>    each data model they each also have to specify the MTI elements.   In
>    addition, the WG has to define how these data models work together (as
>    there may be a specific expected flow or usage for them?).
>
> elements.  *A *SACM Data Models MUST be derived from the SACM Information
> Model.
>
> A SACM Data Model consists of a set of SACM Data Model elements. In this
> derivation, a SACM Data Model element MAY map to one or more SACM
> Information Model elements. In addition, a SACM Data Model MAY include
> additional Data Model elements that are not associated with any SACM
> Information Model elements.
>
>
>
> Nancy (and Henk)
>
>
>
> *From: *John Strassner <[email-masked]>
> *Date: *Tuesday, September 13, 2016 at 9:25 AM
> *To: *"[email-masked]" <[email-masked]>, John Strassner <
> [email-masked]>
> *Cc: *"Haynes, Dan" <[email-masked]>, Adam Montville <
> [email-masked]>, Jim Schaad <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [sacm] Updating DM-001
>
>
>
> Hi all,
>
>
>
> *From: *"Haynes, Dan" <[email-masked]>
> *Date: *Tuesday, September 13, 2016 at 6:47 AM
> *To: *"[email-masked]" <[email-masked]>, John Strassner <
> *Cc: *Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>,
> *Subject: *RE: [sacm] Updating DM-001
>
>
>
> Hi Nancy,
>
>

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 14:13:09 -0700

Hi Nancy (and Henk),

comments inline.

We discussed this in the virtual interim today and decided that we need to
close on this one soon, so we can continue discussions for the next 48hrs
at which point I will update based on results of this thread.
<jcs>
Understood, and sorry for being under the weather and not attending the
virtual interim today.
</jcs>

That said,  John….I’m not sure if your "where each derived SACM Data Model
consists of a set of SACM Data Model elements” the latter was meant to be
“SACM Information Model elements”?  Note that we haven’t defined a SACM
Data Model yet….and I think there is discord to whether there is 1 unifying
SACM Data Model or if a SACM Data Model can be a “subset” of a SACM
Information Model.  The original text intended there to only be one SACM
Data Model that encompassed the information needed to be collected and
assessed.
<jcs>
I'm old-fashioned. To me, the principal value of an information model is to
define a language-, protocol-, and platform-independent specification of
entities of interest and their relationships. This enables multiple data
models to be derived that maintain coherency with each other. For example,
one could have a YANG model, an RDBMS model, and a NoSQL repository model.

Hence, I would vote against **a single** SACM Data Model, as that imposes
constraints on the designer. My implementation will have at least 3 data
models (which happen to be YANG, PostgreSQL, and a GraphDB). I want to
define concepts that each can use once (the SACM Information Model,
singular) that these 3 data models will implement differently (e.g., have
different transformations from THE SACM Information Model to each). Make
sense?

Furthermore, I don't grok "if a SACM Data Model can be a “subset” of a SACM
Information Model". A data model (SACM or otherwise) is a transformation of
an Information model. There can be many transformations (e.g., YANG, RDBMS,
in-memory, etc.). In all of these cases, the data model is not a "subset",
since it is technology-specific, and the info model is
technology-independent. Sorry if I am being academic!
</jcs>

   1. define a single SACM Data Model:  a data model that encompasses all
   of the Information Model elements to allow for posture collection results,
   acquired posture configuration and assessment results that can be
   transported across SACM components.  How posture is collected, configured
   or assessed imho is not in scope for the SACM Data Model….
   2. Define a set of data models that partially address pieces of the SACM
   Information Model  (and can be construed as “SACM IM Compliant”?), as was
   mentioned in the interim today, there may be a data model that is based on
   NEA or OVAL, etc….but are targeted to a specific task.

<jcs>
I do not think that option 1 is viable. All network management
implementations that I am **personally** familiar with use more than one
data model (and not just types of repositories - I could have multiple data
models that each use, for example, an RDBMS). More importantly, I don't
think we will ever agree on a "unified" data model, because that forces
multiple domain- and application-specific implementations agree, which
won't happen.

I think option 2 is on the right track, buuuut... :-)
...A data model could be completely compliant with the SACM Information
Model, in that every element in that data model could be derived from one
or more SACM Information Model elements....
...Similarly, there COULD be data models that have information that are NOT
present in the SACM Information Model.

Hence, the problem is the word "Compliant". What do we do in the latter
case? Is it compliant if there are model elements that are not part of the
SACM Information Model? I **guess** that as long as those "external" (i.e.,
data model elements that are NOT part of the SACM Information Model) data
elements can be related to SACM Information Model elements, you're fine. If
the data model has NO SACM Information Model elements, then I don't know
how you would determine if it is "compliant" or not. See the next comment
(specifically, on MTI).
</jcs>

   - For Option 1: should be more straightforward as the draft would
   specify what is Mandatory to Implement (MTI) from the SACM Data Model.
   - For Option 2:  the WG can define a “minimal” set of these data models
   that MUST be supported to allow for interoperability; also, within each
   data model they each also have to specify the MTI elements.   In addition,
   the WG has to define how these data models work together (as there may be a
   specific expected flow or usage for them?).

<jcs>
I do not think that option 1 is viable.
Option 2 works as long as there is a set of SACM Information Model elements
that are MTI. I don't believe that we have stated that up to now, but
personally, I would be in favor of stating. Then, as long as a data model
has the set of MTI elements, you could add additional (e.g., OVAL) data
model elements and still be "compliant".
</jcs>

OK, that said…..your proposed text ambiguates the notion of 1 SACM DM and
the association of SACM IM elements
<jcs>
See above - ONE SACM DM (to rule them all :-) ) is not a viable option.
</jcs>

Here’s a new proposal:
Sorry, I don't agree with this text - see above.
</jcs>

best regards,
John

On Tue, Sep 13, 2016 at 11:55 AM, Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> From: John Strassner <[email-masked]>
> Cc: "Haynes, Dan" <[email-masked]>, Adam Montville <
>> Regarding your proposed text, I am concerned with the first sentence
>> which says “Each data model element MUST be associated with at least one
>> SACM information model element;”. I think this creates the same problem we
>> were trying to address in the rewrite. Furthermore, it seems to contradict
>> (at least to me) with the last sentence which says “A SACM compliant data
>> model can also define elements that do not directly correspond to any item
>> in the SACM information model.”. Of course, I could be misinterpreting
>> something. We can talk more during the call today.
>>
>>
>>
>> Thanks,
>>
>> Danny
>>
>>
>>

-- 
regards,
John

---

From: Michael Godsey <[email-masked]>
Date: Tue, 13 Sep 2016 21:56:20 +0000

+1 from my perspective as well

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Tuesday, September 13, 2016 1:43 PM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: Haynes, Dan <[email-masked]>; [email-masked]; Nancy Cam-Winget (ncamwing) <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]; John Strassner <[email-masked]>; Adam Montville <[email-masked]>
Subject: Re: [sacm] Updating DM-001

Hi Dave,

+1
Cheers,
- Ira

On Tue, Sep 13, 2016 at 3:58 PM, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
I believe we will minimally need:

Thanks,
Dave

From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, September 13, 2016 2:55 PM
To: John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Haynes, Dan <[email-masked]<mailto:[email-masked]>>; Adam Montville <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi John et al,

Here’s a new proposal:

Nancy (and Henk)

Hi all,

regards,
John

Nancy

Hi Nancy,

----END----

Thanks,

Danny

--
regards,
John

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 14 Sep 2016 10:45:03 +0200

Hello,

Should (Dave's) option 1) and 3) use the same data model? Why use two 
different data models if you require 3) anyways?

Nancy's option 1) is basically Dave's option 3), I think. Nancy's 
proposal is about communication between SACM components (and explicitly 
leaves Dave's option 2 out of scope) -> quote: "results that can be 
transported across SACM components"

Therefore you could be already in agreement here?

tl;dr

1) and 3) seem to be very similar to me. One could argue that there 
could be additional protocols supported to interact with repositories, 
obvious examples being SQL or SPARQL, I think.

2) The actual acquisition of endpoint attributes from a target endpoint 
should be able to use any means/interfaces available (ranging from snmp, 
ofer ssh, to wmi, and indirect acquisition via configuration management 
solutions), as long as the data provenance is captured and included as 
metadata attached to the content acquired when provided to other SACM 
components.

still tl;dr...

If Dave's 1) and 3) can use the same data model, I think Dave maybe also 
agreed to Nancy's option 1)? Dave, please correct me if I am wrong!

Grüße,

Henk

On 09/13/2016 09:58 PM, Waltermire, David A. (Fed) wrote:
> 1)  a data model for interacting with repositories of security
> automation guidance (also a charter item).
>
> different protocol exchanges that support assessment workflows.*
> A* *SACM Data Models MUST be derived from the SACM Information Model.
>
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Nancy
> Cam-Winget (ncamwing)
> *Cc:* Jim Schaad <[email-masked]>;
> [email-masked]; Haynes, Dan <[email-masked]>;
> Adam Montville <[email-masked]>; [email-masked]
> We discussed this in the virtual interim today and decided that we need
> to close on this one soon, so we can continue discussions for the next
> 48hrs at which point I will update based on results of this thread.
>
>
>
> That said,  John….I’m not sure if your "where each derived SACM Data
> Model consists of a set of SACM Data Model elements” the latter was
> meant to be “SACM Information Model elements”?  Note that we haven’t
> defined a SACM Data Model yet….and I think there is discord to whether
> there is 1 unifying SACM Data Model or if a SACM Data Model can be a
> “subset” of a SACM Information Model.  The original text intended there
> to only be one SACM Data Model that encompassed the information needed
> to be collected and assessed.
>
>
>
> By “unifying”, I do think we will need to demonstrate how
> implementations can interoperate and I think it can only be achieved in
> one of 2 ways:
>
>     of the Information Model elements to allow for posture collection
>     results, acquired posture configuration and assessment results that
>     can be transported across SACM components.  How posture is
>     collected, configured or assessed imho is not in scope for the SACM
>     Data Model….
>     SACM Information Model  (and can be construed as “SACM IM
>     Compliant”?), as was mentioned in the interim today, there may be a
>     data model that is based on NEA or OVAL, etc….but are targeted to a
>     specific task.
>
>   * For Option 1: should be more straightforward as the draft would
>   * For Option 2:  the WG can define a “minimal” set of these data
>     models that MUST be supported to allow for interoperability; also,
>     within each data model they each also have to specify the MTI
>     elements.   In addition, the WG has to define how these data models
>     work together (as there may be a specific expected flow or usage for
>     them?).
>
> elements.  *A *SACM Data Models MUST be derived from the SACM
> Information Model.
>
> *From: *John Strassner <[email-masked] <mailto:[email-masked]>>
> *To: *"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, John Strassner
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *"Haynes, Dan" <[email-masked] <mailto:[email-masked]>>, Adam
> Montville <[email-masked]
> <mailto:[email-masked]>>, Jim Schaad <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>,
> "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>
> sense for me to attend. However, regarding the above discussion, I
> believe the confusion is because the first sentence is talking about a
> 1..n relationship between an unspecified data model element to the SACM
> info model element, whereas the second sentence introduces the term
> **data model**, and says that a SACM data model MAY include additional
> data model elements.
>
>
>
> Information Model, where each derived SACM Data Model consists of a set
> of SACM Data Model elements. In this derivation, a SACM Data
> Model element MAY be derived from one or more SACM Information Model
> elements. In addition, a SACM Data Model MAY include additional Data
> Model elements that are not associated with any SACM Information Model
> elements. For example, two SACM Information Model elements could be
> mapped to a single SACM Data Model element. As another example, a SACM
> Data Model element does not need to directly correspond to any SACM
> Information Model element.
>
>
>
> regards,
>
> John
>
>
>
> On Tue, Sep 13, 2016 at 9:07 AM, Nancy Cam-Winget (ncamwing)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Danny,
>
>
>
>     example…..” is really about describing how a data model element can
>     map to more than one information model element but the previous
>     sentence goes to state that extensions can be made to a data model
>     that are not part of the SACM IM.  Which is why I changed that ordering.
>
>
>
>     I’m not sure why you think my split of your first sentence into 2
>     clauses is confusing….as it is basically saying the same thing?
>
>
>
>
>
>     Nancy
>
>
>
>     *From: *"Haynes, Dan" <[email-masked] <mailto:[email-masked]>>
>     *To: *"[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>, John Strassner
>     <[email-masked] <mailto:[email-masked]>>, Adam Montville
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Jim Schaad <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     definitely get to discuss it. For the slides, I included the
>     following text which I came up with based on feedback in this thread.
>
>
>
>     ----START----
>
>     Each data model element that is derived from the SACM Information
>     Model MUST be associated with at least one SACM Information Model
>     element and MAY be associated with more than one SACM Information
>     Model element. A SACM data model MAY include additional data model
>     elements that are not associated with any SACM Information Model
>     elements. For example, two SACM Information Model elements from the
>     SACM Information Model could be mapped to a single SACM data model
>     element. As another example, a SACM data model element does not need
>     to directly correspond to any item in the SACM Information Model
>     _element_.
>
>     ----END----
>
>
>
>     which says “Each data model element MUST be associated with at least
>     one SACM information model element;”. I think this creates the same
>     problem we were trying to address in the rewrite. Furthermore, it
>     seems to contradict (at least to me) with the last sentence which
>     says “A SACM compliant data model can also define elements that do
>     not directly correspond to any item in the SACM information model.”.
>     Of course, I could be misinterpreting something. We can talk more
>     during the call today.
>
>
>
>     Thanks,
>
>     Danny
>
>
>
>     > To: John Strassner <[email-masked] <mailto:[email-masked]>>; Adam Montville
>
>     > <[email-masked] <mailto:[email-masked]>>
>
>     > Cc: Jim Schaad <[email-masked] <mailto:[email-masked]>>; Haynes, Dan
>     <[email-masked] <mailto:[email-masked]>>;
>
>     > [email-masked] <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>
>     > On 8/1/16, 12:40 PM, "John Strassner" <[email-masked] <mailto:[email-masked]>> wrote:
>
>     >
>
>     > >Hi Adam,
>
>     > >
>
>     > ><[email-masked] <mailto:[email-masked]>
>
>     > >> wrote:
>
>     > >
>
>     > >>
>
>     > >> [email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     > >> >
>
>     > >> > Hi Adam,
>
>     > >> >
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 15 Sep 2016 15:37:57 +0000

This text works for me as well.

Thanks,

Danny

From: Ira McDonald [mailto:[email-masked]]
Sent: Tuesday, September 13, 2016 4:43 PM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: Nancy Cam-Winget (ncamwing) <[email-masked]>; John Strassner <[email-masked]>; Jim Schaad <[email-masked]>; Haynes, Dan <[email-masked]>; [email-masked]; [email-masked]; Adam Montville <[email-masked]>
Subject: Re: [sacm] Updating DM-001

Hi Dave,

+1
Cheers,
- Ira

Thanks,
Dave

Hi John et al,

Here’s a new proposal:

Nancy (and Henk)

Hi all,

regards,
John

Nancy

Hi Nancy,

----END----

Thanks,

Danny

--
regards,
John