Subject: [sacm] Should the SACM information model I-D discuss the graph model?

From: "Kahn, Clifford" <[email-masked]>
Date: Tue, 14 Oct 2014 00:51:44 +0000

Dear SACM WG:

At the 2014-09-10 virtual meeting, we debated, but did not resolve, whether the SACM information model I-D should discuss the graph model. I recall taking an action item to write to the list about it. This belated memo fulfills that action item.

>From the minutes of the September meeting:
* Dan - how does the Graph Model (5) related to the Info model (4) 
* Lisa - sect 4 is about organization. Sec 5 is about enumeration 
* Dan R - We may want to talk about the graph representation as an appendix or separate document that explains the usage of the more complex structures. I don't think we need to list all the elements, instances and attributes and representing them through the graph model. Maybe we need an example or two. I'm still fighting whether graph model belongs here as an appendix or a separate document. 
* Jim Bieda - Graph model seems like an implementation choice. Is it a should or a must or an option. 
* Lisa - Open question? Jim - there is an opportunity to work this for the next call and meeting. 
* Dave W - if we don't use graph notation in this document, then what should be use instead? 
* Dan R - maybe UML. Also, maybe section 6 should be merged into section 5. 
* Lisa - Looking for helping writing section 6 without graph terminology. (chuckles). 

Here are my further comments. 

I don't know how suitable a graph model is. Endpoint attribute assertions are at the heart of the proposed information model (see section 4.7 of the I-D). Endpoint attribute assertions seem like tuples. They seem relational. Maybe there is a good graph notation for them; maybe we will adopt it. But it seems productive to *first* refine and agree on concepts like endpoint attribute assertion, and *then* work out how to represent them. 

Even so, let us suppose for a moment that we decided to use the graph model approach proposed in section 5 of draft-combined-sacm-information-model-00. That decision would leave open issues. Should hardware component, hardware instance, software component, and software instance be four identifier types? (See Figure 1 of the I-D.) Or should all of these be captured in a Yang description of the endpoint?  The Yang description would be attached to an endpoint identifier, as metadata.  Both representations seem to have merit. It seems premature to answer the question now. It seems better handled in a data model document.  

In conclusion, it seems premature to focus on a graph model. The UML notation in Figure 1 of the I-D floats at a higher level; this level seems more suitable for the information model. Can we agree to take section 5 out of the body of the information model I-D? We can move it to an appendix for now, and consider it when we work on data models.  

Best,
			Cliff

Clifford Kahn
Principal Engineer/Technical Lead
Pulse Secure