Subject: Re: [sacm] New version of the information model diagram

From: Clifford Kahn <[email-masked]>
Date: Sun, 1 Feb 2015 17:37:16 +0000

With glitches in the figure fixed (sorry)

From: Clifford Kahn
Sent: Sunday, February 01, 2015 12:33 PM
To: [email-masked]'
Subject: New version of the information model diagram

All,
I reference draft-ietf-sacm-information-model-00.

I would eliminate figure 1. It's redundant.

I would change
                "Figure 2 depicts an instance of the information model."
to
                "Figure 1 depicts the information model."

Here is a new version of the figure.  (View the figure using a fixed-width font, such as Courier.)

  +---------+ +---------+              +--------+____________________
  |Hardware | |Software |    __________|Location|*_______________    |
  |Component| |Component|   |         *+--------+*               |   |
  +---------+ +---------+   |                                    |   |
       |1          |1       |         +----------+               |   |
       |*          |*       |   ______|Credential|____________   |   |
  +---------+ +--------+    |  |     *+----------+*           |* |*  |
  |Hardware | |Software|    |  |         +---------+       +-------+ |
  |Instance | |Instance|    |  |         |Network  |_______|Account| |
  +---------+ +--------+    |  |         |Session  |*  0..1+-------+ |
       |*      |*          *| *|         |- - - - -|                *|
       |       |____1+----------+1______*|Network  |__________+-------+
       |_____________| Endpoint |_____   |Interface|*     1..*|Address|
                    1|          |0..1 |  +---------+          +-------+
                     +----------+     |      1|
          _____________|1    |*       |       |_____+-------------+
         |                   |________|            *|Authorization|
         |                    part-of>              +-------------+
  .......|..............................................................
         |            |0..1
         |            |
         |            |*
         |         +-----+            +---------+___________________
         |         | AVP |____________|Endpoint |1..*   <based-on   |
        ^|         +-----+1..*       1|Attribute|________           |
hosted-by|           *|               |Assertion|*       |          |
         |            |               +---------+        |          |
         |            |produced-using   |*    |*         |         *|
         |           1|V                |     |__________|     +-------+
         |        +--------+            |       <based-on      |Summary|
         |        | Method |            |                      +-------+
         |        +--------+            |produced-by               *|
         |____________________          |V                          |
                              |*       1|                           |
    +--------+1____________*+-----------+                           |
    |        |    guides>   | SACM      |___________________________|
    |Guidance|              | Component |1       <produced-by
    +--------+*____________1+-----------+
               <produced-by

         -------------------------------------------------------------
         ..... Above this line is the monitorable world
         -------------------------------------------------------------

The figure has additions for provenance:

*         A class "Method"

*         The produced-using relationship between an AVP and  a Method

*         The produced-by relationship between a Guidance and a SACM Component

*         The hosted-by relationship between a SACM Component and an Endpoint

The figure has other changes:

*         asserted-by and summarized-by have been renamed to produced-by.

*         "User" is now "Account". If a user has different credentials, SACM cannot know that they belong to the same user. But, per Kim W, many organizations do have accounts that associate credentials.

*         The multiplicity of the based-on relationships have been corrected.

*         More relationships now have labels, per UML convention.

*         I got rid of the causal arrows, which had become redundant and were nonstandard and clutter.

Still to come:

*         We are still discussing network sessions and network interfaces and how to model them. I left that part of the figure alone for now.

*         More provenance.

*         Should Level of Assurance be a class?

*         If an endpoint provides information about itself to an external attribute collector, which turns the information into SACM notation, how do we model the endpoint's and the collector's parts in the chain of custody?

*         Will a SACM controller ever add an AVP to an endpoint attribute assertion? If so, how will we model that?

*         Coverage. I know Kim is interested in capturing enough information so that gaps in coverage can be found. (Is this in our requirements? It should be, I think.) She has suggested something like, each SACM component should publish a description of what it covers. The "guides" relationship might look sufficient, but it isn't. If a piece of guidance says "Capture the SWID tag inventory", a SACM component can heed that, but only for some endpoints.

Clifford Kahn
Principal Engineeer, Technical Lead

---

From: Clifford Kahn <[email-masked]>
Date: Sun, 1 Feb 2015 19:42:28 +0000

A bug:

A summary can be based-on summaries. And a summary is produced-using a method.

Best,
                                                Cliff

From: Clifford Kahn [mailto:[email-masked]]
Sent: Sunday, February 01, 2015 12:37 PM
To: [email-masked]
Subject: Re: [sacm] New version of the information model diagram

From: Clifford Kahn

All,

I would change

*         A class "Method"

Still to come:

*         More provenance.

Clifford Kahn

---

From: Ira McDonald <[email-masked]>
Date: Sun, 1 Feb 2015 15:45:31 -0500

Hi Cliff,

Your first note had a fairly complete diagram with fixed-width font.

Your second note had an incomplete garbage diagram.

Perhaps a simple plaintext attachment would help?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sun, Feb 1, 2015 at 12:37 PM, Clifford Kahn <[email-masked]>
wrote:

> *From:* Clifford Kahn
> *Sent:* Sunday, February 01, 2015 12:33 PM
> *To:* [email-masked]'
> *Subject:* New version of the information model diagram
>
>
>
> All,
>
>                 “Figure 2 depicts an instance of the information model.”
>
> to
>
>                 “Figure 1 depicts the information model.”
>
>
>
> ·         A class "Method"
> ·         The produced-using relationship between an AVP and  a Method
>
> ·         The produced-by relationship between a Guidance and a SACM
> Component
>
> ·         The hosted-by relationship between a SACM Component and an
> Endpoint
>
>
>
> ·         asserted-by and summarized-by have been renamed to produced-by.
>
> ·         "User" is now "Account". If a user has different credentials,
> SACM cannot know that they belong to the same user. But, per Kim W, many
> organizations do have accounts that associate credentials.
>
> ·         The multiplicity of the based-on relationships have been
> corrected.
>
> ·         More relationships now have labels, per UML convention.
>
> ·         I got rid of the causal arrows, which had become redundant and
> were nonstandard and clutter.
>
>
>
> Still to come:
>
> ·         We are still discussing network sessions and network interfaces
> and how to model them. I left that part of the figure alone for now.
>
> ·         More provenance.
>
> ·         Should Level of Assurance be a class?
>
> ·         If an endpoint provides information about itself to an external
> attribute collector, which turns the information into SACM notation, how do
> we model the endpoint's and the collector's parts in the chain of custody?
>
> ·         Will a SACM controller ever add an AVP to an endpoint attribute
> assertion? If so, how will we model that?
>
> ·         Coverage. I know Kim is interested in capturing enough
> information so that gaps in coverage can be found. (Is this in our
> requirements? It should be, I think.) She has suggested something like,
> each SACM component should publish a description of what it covers. The
> "guides" relationship might look sufficient, but it isn't. If a piece of
> guidance says "Capture the SWID tag inventory", a SACM component can heed
> that, but only for some endpoints.
>
>
>
>
>
> Clifford Kahn
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: Clifford Kahn <[email-masked]>
Date: Mon, 2 Feb 2015 13:08:02 +0000

Thanks, Ira. Sorry for the problems! Here is the diagram as an attachment.

I sneaked in one correction to multiplicity.

Best,
                                                Cliff

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Feb 2015 09:41:35 -0800

I am having a problem with the picture when dealing with the two pairs
Hardware Component/Hardware Instance and Software Component/Software
Instance.  If I understand the picture correct there is a single component
with multiple instances that are mapped into an end point.  However this
does not seem to reflect the reality that there are actually multiple
components that should be mapped to the end point.

I believe that these two pairs of components needs to be separated from the
main diagram and two new objects created Hardware Asset and Software Asset
(based on the description in 4.8.2 Asset is probably not correct as it does
not include the "evil" software side).   There would then be a multi to one
mapping from Hardware Asset and Software Asset to the end point.

Jim

From: sacm [mailto:[email-masked]] On Behalf Of Clifford Kahn
Sent: Sunday, February 01, 2015 9:37 AM
To: [email-masked]
Subject: Re: [sacm] New version of the information model diagram

From: Clifford Kahn 

All,

I would change

to

Here is a new version of the figure.  (View the figure using a fixed-width
font, such as Courier.)

       |1          |1       |         +----------+               |   |

                     +----------+     |      1|

         |            |0..1            

         |            |               

         |            |*              

         |            |               +---------+        |          |

         |        | Method |            |                      +-------+

                              |*       1|                           |

               <produced-by

.         A class "Method"

.         The produced-using relationship between an AVP and  a Method

.         The produced-by relationship between a Guidance and a SACM
Component

.         The hosted-by relationship between a SACM Component and an
Endpoint

.         asserted-by and summarized-by have been renamed to produced-by.

.         "User" is now "Account". If a user has different credentials, SACM
cannot know that they belong to the same user. But, per Kim W, many
organizations do have accounts that associate credentials. 

.         The multiplicity of the based-on relationships have been
corrected. 

.         More relationships now have labels, per UML convention. 

.         I got rid of the causal arrows, which had become redundant and
were nonstandard and clutter. 

Still to come:

.         We are still discussing network sessions and network interfaces
and how to model them. I left that part of the figure alone for now.

.         More provenance. 

.         Should Level of Assurance be a class? 

.         If an endpoint provides information about itself to an external
attribute collector, which turns the information into SACM notation, how do
we model the endpoint's and the collector's parts in the chain of custody? 

.         Will a SACM controller ever add an AVP to an endpoint attribute
assertion? If so, how will we model that? 

.         Coverage. I know Kim is interested in capturing enough information
so that gaps in coverage can be found. (Is this in our requirements? It
should be, I think.) She has suggested something like, each SACM component
should publish a description of what it covers. The "guides" relationship
might look sufficient, but it isn't. If a piece of guidance says "Capture
the SWID tag inventory", a SACM component can heed that, but only for some
endpoints.

Clifford Kahn

---

From: Clifford Kahn <[email-masked]>
Date: Tue, 10 Feb 2015 17:59:26 +0000

Thanks, Jim.

I'll take the pair Hardware Component/Hardware Instance.

The UML diagram doesn't say that Hardware Instance is a singleton.

The diagram says that the relationship between an endpoint and a hardware instance is 1:* (one-to-many).
   - An endpoint can have many hardware instances.
   - A hardware instance belongs to exactly one endpoint.

It says that the relationship between a hardware instance and a hardware component is *:1 (many-to-one).
    - A hardware instance is an instance of one hardware component.
    - A hardware component has many instances.

Does that address your concern?

Best,
                                                Cliff

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, February 10, 2015 12:42 PM
To: Clifford Kahn; [email-masked]
Subject: RE: [sacm] New version of the information model diagram

I am having a problem with the picture when dealing with the two pairs Hardware Component/Hardware Instance and Software Component/Software Instance.  If I understand the picture correct there is a single component with multiple instances that are mapped into an end point.  However this does not seem to reflect the reality that there are actually multiple components that should be mapped to the end point.

I believe that these two pairs of components needs to be separated from the main diagram and two new objects created Hardware Asset and Software Asset  (based on the description in 4.8.2 Asset is probably not correct as it does not include the "evil" software side).   There would then be a multi to one mapping from Hardware Asset and Software Asset to the end point.

Jim

From: sacm [mailto:[email-masked]] On Behalf Of Clifford Kahn
Sent: Sunday, February 01, 2015 9:37 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] New version of the information model diagram

From: Clifford Kahn

All,

I would change

*         A class "Method"

Still to come:

*         More provenance.

Clifford Kahn

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Feb 2015 10:08:15 -0800

Yes, but from the picture I don't understand that an endpoint can have
multiple hardware components

Jim

From: Clifford Kahn [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2015 9:59 AM
To: Jim Schaad; [email-masked]
Subject: RE: [sacm] New version of the information model diagram

Thanks, Jim.

The diagram says that the relationship between an endpoint and a hardware
instance is 1:* (one-to-many). 

It says that the relationship between a hardware instance and a hardware
component is *:1 (many-to-one).  

Best,

                                                Cliff

Jim

From: Clifford Kahn 

All,

I would change

to

       |1          |1       |         +----------+               |   |

                     +----------+     |      1|

         |            |0..1            

         |            |               

         |            |*              

         |            |               +---------+        |          |

         |        | Method |            |                      +-------+

                              |*       1|                           |

               <produced-by

.         A class "Method"

Still to come:

.         More provenance. 

 

Clifford Kahn