Subject: Re: [sacm] Updating DM-001

From: John Strassner <[email-masked]>
Date: Mon, 1 Aug 2016 15:13:10 -0400

Sorry for the delay, am on travel.

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

<jcs>
Element is fine, as long as we define what an "element" is. Apologies
for thinking artifact was more generic (YMMV as Jim says). I don't
like object or entity because these things are really attributes and
data structures, and object and entity connote more. Good try though :-)
</jcs>

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?

<jcs>
Sorry, you lost me on this one Jerome.
The original comments were:
>> 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".
>
> It says "A SACM data model MAY ..."

To which I reply that "a" means one of many. It there was only one,
it would be "The SACM data model...".

And this is precisely the point. If I build a NoSQL SACM DM, an
RDBMS SACM DM, and a YANG SACM DM, they are going to look
very different. Plus, depending on the application, I don't need to
map all of the SACM IM, right? Hence, there will always be multiple
SACM DMs. If we don't need multiple SACM DMs, then we really
don't need an IM in the first place, since it is a direct 1:1 mapping.
However, I've built management systems for well over 25 years,
and I've never used "just one" DM.
</jcs>

...

regards,
John

On Fri, Jul 29, 2016 at 12:08 AM, Jerome Athias <[email-masked]>
wrote:

> 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.
>
>
>
> On Fri, Jul 29, 2016 at 4:07 AM, Jim Schaad <[email-masked]>
> wrote:
> >
> >
> >> -----Original Message-----
> >> 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]
> >> Cc: [email-masked]
> >> Subject: RE: [sacm] Updating DM-001
> >>
> >> 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"?
> >
> > 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.
> >
> >>
> >> > 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.
> >
> > 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.
> >
> >>
> >> 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".
> >
> > It says "A SACM data model MAY ..."
> >
> > Jim
> >
> >>
> >> > 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.
> >>
> >> 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
> >>
> >> 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
> >>
> >>
> >> > -----Original Message-----
> >> > 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]>
> >> > Cc: [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
> >> >
> >> > > -----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
> >> >
> >> > _______________________________________________
> >> > sacm mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/sacm
> >>
> >> _______________________________________________
> >> sacm mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sacm
> >
> > _______________________________________________
> > sacm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sacm
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 1 Aug 2016 15:40:05 -0400

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

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

>
> > On Jul 28, 2016, at 5:20 PM, John Strassner <
> [email-masked]> wrote:
> >
> > Hi Adam,
> >
> >> 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.
>
> >
> >> 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?
>
> 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.
>
> >
> > ...
> >
> >> 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).
>
>
> 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.
>
>
> >
> > regards,
> > John
> >
> >
> > 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]
> > 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.
> >
> > 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”.
> >
> > 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?
> >
> >>
> >>

-- 
regards,
John