Subject: [sacm] Updating DM-001

From: Adam Montville <[email-masked]>
Date: Thu, 28 Jul 2016 09:23:55 -0500

Hello.  One of the actions we have as a WG is to get DM-001 updated quickly, so that we can submit the draft to the IESG within the next week or so.  Has anyone provided the authors with suggested text?

Kind regards,

Adam

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 28 Jul 2016 19:30:55 +0000

Hi Everyone,

Here is some proposed text for DM-001.  Please let Henk, John Strassner, and myself know if you have any feedback.

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

Thanks,

Danny

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
> Sent: Thursday, July 28, 2016 10:24 AM
> To: <[email-masked]> <[email-masked]>
> Cc: [email-masked]
> Subject: [sacm] Updating DM-001
> 
> Hello.  One of the actions we have as a WG is to get DM-001 updated quickly,
> so that we can submit the draft to the IESG within the next week or so.  Has
> anyone provided the authors with suggested text?
> 
> Kind regards,
> 
> Adam

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Jul 2016 13:27:34 -0700

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
2.  This statement departs from the previous statement that there is ONE
SACM IM but other IMs can exist which have not yet met the Highlander
requirement.
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.

I am against adopting this text.

Jim

> From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
> Sent: Thursday, July 28, 2016 12:31 PM
> To: Adam Montville <[email-masked]>; <[email-masked]>
> <[email-masked]>
> Subject: Re: [sacm] Updating DM-001
> 
> Hi Everyone,
> 
> Here is some proposed text for DM-001.  Please let Henk, John Strassner,
and
> myself know if you have any feedback.
> 
> ----START----
> Each data model artifact that is derived from the SACM Information model
> MUST be associated with at least one SACM information model artifact and
> MAY be associated with more than one SACM information model artifact. A
> SACM data model MAY include additional data model artifacts that are not
> associated with any SACM information model artifacts. For example, two
SACM
> information model artifacts from the SACM information model could be
mapped
> to a single SACM data model artifact. As another example, a SACM data
model
> artifact does not need to directly correspond to any item in the SACM
> information model.
> ----END----
> 
> Thanks,
> 
> Danny
> 
> > Hello.  One of the actions we have as a WG is to get DM-001 updated
> > quickly, so that we can submit the draft to the IESG within the next
> > week or so.  Has anyone provided the authors with suggested text?
> >
> > Kind regards,
> >
> > Adam
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Thu, 28 Jul 2016 15:43:02 -0500

As contributor...

> On Jul 28, 2016, at 3:27 PM, Jim Schaad <[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.

While the existing text does flow better, the proposed text is more specific and not really subject to interpretation, which is what I think we were after.

> SACM IM but other IMs can exist which have not yet met the Highlander

I am not interpreting any of the proposed text to suggest that there is more than one IM.  Phrases like “the SACM Information model”, “any SACM information model artifacts”, “one SACM information model artifact”, would support my conclusion.  Where “more than one” or “any” is used in the context of the information model, the subject is “information model artifact” not “information model”.

> statement does not make sense to me.

I think I agree here—that a single data model element would fit into two IM elements seems off.  But, there may be a valid case…is there?

---

From: John Strassner <[email-masked]>
Date: Thu, 28 Jul 2016 22:11:31 +0000

Hi Jim,

> The one currently in the document both reads more smoothly and is
> far more understandable to me that what is below.

I disagree.
First, it has ambiguous terms as well. For example, What is a
"data model element"? What is an "information model element"? 
Second, it states: " The data model MUST contain a data model
element for each information model element...". This is just
plain wrong. Common modeling practice is to optimize a data
model to application-specific needs, whereas an information
model should make explicit different objects and relationships
between objects (similar to normalization in databases). For
example, if I have a set of abstract classes, they cannot be
instantiated. Period. Instead, their attributes, methods,
relationships, and other properties will be inherited and
realized by a single data model object.

> 1.  what the blazes is an artifact - this is a new concept that
> I don't understand

>From Merriam-Webster:
a :   something created by humans usually for a practical purpose...
>From Wikipedia
(https://en.wikipedia.org/wiki/Artifact_(software_development)
An artifact is one of many kinds of tangible by-products produced
during the development of software...The term artifact in connection
with software development is largely associated with specific
development methods or processes

We used this term to avoid saying "element"; artifact is used more
in software development.

If you have a more intuitive term, please suggest one.

> 2.  This statement departs from the previous statement that
> there is ONE SACM IM but other IMs can exist which have not yet
> met the Highlander requirement.

Why do you say this? It says "the SACM Information model", which
implies one. Both requirements say that data model "thingies"
may not be associated with a SACM IM "thingie".

> elements, then this is a fault in the IM and should be fixed there.
> That statement does not make sense to me.

See my first explanation.

regards,
John

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, July 28, 2016 1:28 PM
To: 'Haynes, Dan'; 'Adam Montville'; [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Updating DM-001

Jim

and
SACM
mapped
model

---

From: John Strassner <[email-masked]>
Date: Thu, 28 Jul 2016 22:20:13 +0000

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.

> While the existing text does flow better, the proposed text is
> more specific and not really subject to interpretation, which is
> what I think we were after.

Why does the new text not flow as well as the old text?

...

> I think I agree here—that a single data model element would fit into
> two IM elements seems off.  But, there may be a valid case…is there?

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).

regards,
John

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, July 28, 2016 1:43 PM
To: Jim Schaad
Cc: Haynes, Dan; [email-masked]; [email-masked]
Subject: Re: [sacm] Updating DM-001

As contributor...

> 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

> 2.  This statement departs from the previous statement that there is 
> ONE SACM IM but other IMs can exist which have not yet met the 
> Highlander requirement.

>> Each data model artifact that is derived from the SACM Information 
>> model MUST be associated with at least one SACM information model 
>> artifact and MAY be associated with more than one SACM information 
>> model artifact. A SACM data model MAY include additional data model 
>> artifacts that are not associated with any SACM information model 
>> artifacts. For example, two
> SACM

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Jul 2016 18:07:47 -0700

> From: John Strassner [mailto:[email-masked]]
> Sent: Thursday, July 28, 2016 3:12 PM
> To: Jim Schaad <[email-masked]>; 'Haynes, Dan'
<[email-masked]>;
> 'Adam Montville' <[email-masked]>; [email-masked];
> [email-masked]
> Subject: RE: [sacm] Updating DM-001
> 
> Hi Jim,
> 
> First, it has ambiguous terms as well. For example, What is a "data model
> element"? What is an "information model element"?

And you have not solved that problem so I would prefer to use the original
language as it is less ambiguous to me.  You are always going to have some
degree of ambiguity given that people need to have to agree on wording
because of the different way that they view the world.

> Second, it states: " The data model MUST contain a data model element for
> each information model element...". This is just plain wrong. Common
modeling
> practice is to optimize a data model to application-specific needs,
whereas an
> information model should make explicit different objects and relationships
> between objects (similar to normalization in databases). For example, if I
have a
> set of abstract classes, they cannot be instantiated. Period. Instead,
their
> attributes, methods, relationships, and other properties will be inherited
and
> realized by a single data model object.

Please remember that we are making a requirement on THE SACM DM not a
requirement on all DMs that can be created from SACM IM.  This means that we
are not looking at any application-specific needs, we are looking at a
general purpose DM that can be used for all applications.  What you might do
for a SWID only DM is not covered by this requirement.

> An artifact is one of many kinds of tangible by-products produced during
the
> development of software...The term artifact in connection with software
> development is largely associated with specific development methods or
> processes
> 
> We used this term to avoid saying "element"; artifact is used more in
software
> development.

YMMV - I have used the term element many times in doing software
development, but have never used the term artifact except in the meaning
that is usually assigned to it in the archeology sense.  That is, I use
artifact almost entirely in the physical sense.  This means that it does not
read smoothly because I need to pull in a strange concept.  I would prefer
to use element as I feel it is more common in this sense.

> Why do you say this? It says "the SACM Information model", which implies
one.
> Both requirements say that data model "thingies"

It says "A SACM data model MAY ..."

Jim

> 1.  what the blazes is an artifact - this is a new concept that I don't
understand 2.
> This statement departs from the previous statement that there is ONE SACM
IM
> but other IMs can exist which have not yet met the Highlander requirement.
elements,
> then this is a fault in the IM and should be fixed there.  That statement
does not
> make sense to me.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 29 Jul 2016 07:08:51 +0300

I've seen good comments. (e.g. hierarchy and abstract classes)

This highlights, again, the known for years issue: the lack of one
unified cyber(security) Ontology (consensus on semantics and
hierarchy. adapted to all context)

Regarding:
1) element vs artifact. While I'm not aware of a complete "Webster for
Cyber", I unfortunately concur that meaning of cyber-related words
will be different in each of our mind, based on our own experience,
etc.
We could use a poll. maybe (for now I prefere "element")
Putting there other words, just for thinking: construct, object, entity

2) While in few words I would argue that "everything is somehow
related", for being able to produce (and so for being able to argue
that one produced) an exhaustive IM of DM of "everything in
cyber(security)", I would resume in one question (hopefully not
misinterpreted): Do you believe in God?

3) I agree with the arguments talking about hierarchies and abstract
classes. It depends the level of Abstraction wanted/used. (in a given
context/scope)
e.g.:
A Device is an Asset - or an IT-Asset and/or an Hardware thing and/or
a Composition of Components (+/- Software) and/or Atoms, etc.
A Software is a Composition of Files/Artifacts and/or a Binary and/or
a Binary and Components and/or is composed of Source Code and/or is an
instance of the translation of Human-based instructions into a
Language understandable by a Machine and/or are Opcodes in Memory at
runtime, etc., etc.

---

From: Adam Montville <[email-masked]>
Date: Fri, 29 Jul 2016 09:01:33 -0500

> On Jul 28, 2016, at 5:20 PM, John Strassner <[email-masked]> wrote:
> 
> Hi Adam,
> 

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.

> Why does the new text not flow as well as the old text?

It feels very…utilitarian?  It’s not as free form as the original, but I don’t think we want free from.  We want specific.  So, it’s good.

> 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.

I’m thinking less in terms of software and more in terms of serialization, which might be the reason for differing perspectives.  In terms of software, I don’t care how things are implemented.  I care about the structure of the data when it is shuffled from one component to the next.