Subject: [sacm] Question about DM Requirements

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 21 Jun 2016 17:54:17 +0000

I was reviewing the DM requirements based on the SWID M&A call for adoption thread and had some questions.

In Section 2 of the Requirements, it says:

                    "Multiple data models, protocols, and transports may be employed in a SACM environment..."

Then DM-001 says:

"DM-001  Element Association: The data model MUST contain a data model element for each information model element (e.g. endpoint, IP address, asset).  In other words, for every item in the information model, there must be an item in the data model.  The data model can also include elements that do not exist in the information model."

Does this requirement conflict with the text above in Section 2 by saying that every DM must contain an element for each IM element?  That is, each DM must support the entire IM and it is not possible for a DM to just support a portion of the IM.

Also, DM-002 says:

"DM-002  Data Model Structure: The data model can be structured either as one single module or separated into modules and sub-modules that allow for references between them.  The data model structure MAY reflect structure in the information model, but does not need to. For example, the data model might use one module to define endpoints, and that module might reference other modules that describe the various assets associated with the endpoint. Constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g. same IP address used in two separate networks)."

Is this effectively reiterating that a DM must support everything in the IM, but, that the DM can choose to break it up into submodules if they so choose?

Thanks,

Danny

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Jun 2016 15:07:10 -0400

Hi Danny,

My two cents.

A conforming *subset* Data Model should be perfectly acceptable
in SACM (e.g., one optimized for roaming mobile devices).

That DM-02 statement:

  "The data model structure MAY reflect structure in the information
  model, but does not need to."

makes me uncomfortable...

Changing packaging is OK, but changing the structure (i.e., hierarchy)
of the IM sounds wrong to me.

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 Tue, Jun 21, 2016 at 1:54 PM, Haynes, Dan <[email-masked]> wrote:

>                     “Multiple data models, protocols, and transports may be employed in a SACM environment…”
>
>
>
> Then DM-001 says:
>
>
>
> “DM-001  Element Association: The data model MUST contain a data model element for each information model element (e.g. endpoint, IP address, asset).  In other words, for every item in the information model, there must be an item in the data model.  The data model can also include elements that do not exist in the information model.”
>
>
>
> “DM-002  Data Model Structure: The data model can be structured either as one single module or separated into modules and sub-modules that allow for references between them.  The data model structure MAY reflect structure in the information model, but does not need to. For example, the data model might use one module to define endpoints, and that module might reference other modules that describe the various assets associated with the endpoint. Constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g. same IP address used in two separate networks).”
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 21 Jun 2016 19:31:35 +0000

Hi Ira,

Thanks for the feedback!

By “packaging”, do you mean data format (e.g. xml, cbor, etc.)?

Also, with respect to your concern about changing the “structure”, maybe we want it to say something like the DM must maintain relationships between information elements in the IM?

Thanks,

Danny

From: Ira McDonald [mailto:[email-masked]]
Sent: Tuesday, June 21, 2016 3:07 PM
To: Haynes, Dan <[email-masked]>; Ira McDonald <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] Question about DM Requirements

Hi Danny,
My two cents.

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

On Tue, Jun 21, 2016 at 1:54 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:
I was reviewing the DM requirements based on the SWID M&A call for adoption thread and had some questions.

Then DM-001 says:

Also, DM-002 says:

Thanks,

Danny

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Jun 2016 18:13:44 -0400

Hi Dan,

Yes by "packaging" I meant to loosely refer to encoding (XML, JSON, etc.).

And I like clarifying that maintaining structure is maintaining
relationships
(parent/child, dependencies, and others) between info/data elements.

Cheers,
- Ira

On Tue, Jun 21, 2016 at 3:31 PM, Haynes, Dan <[email-masked]> wrote:

> Also, with respect to your concern about changing the “structure”, maybe
> we want it to say something like the DM must maintain relationships between
> information elements in the IM?
>
>
>
> Thanks,
>
> Danny
>
>
>
> *From:* Ira McDonald [mailto:[email-masked]]
> *Sent:* Tuesday, June 21, 2016 3:07 PM
> *To:* Haynes, Dan <[email-masked]>; Ira McDonald <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] Question about DM Requirements
>
>
>
> Hi Danny,
>
> My two cents.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 21 Jun 2016 18:29:36 -0700

Just my $0.02

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, June 21, 2016 10:54 AM
To: [email-masked]
Subject: [sacm] Question about DM Requirements

I was reviewing the DM requirements based on the SWID M&A call for adoption
thread and had some questions.

In Section 2 of the Requirements, it says:
                    "Multiple data models, protocols, and transports may be
employed in a SACM environment."
 
Then DM-001 says:
 
"DM-001  Element Association: The data model MUST contain a data model
element for each information model element (e.g. endpoint, IP address,
asset).  In other words, for every item in the information model, there must
be an item in the data model.  The data model can also include elements that
do not exist in the information model."
 
Does this requirement conflict with the text above in Section 2 by saying
that every DM must contain an element for each IM element?  That is, each DM
must support the entire IM and it is not possible for a DM to just support a
portion of the IM.
 
[JLS] I see no conflict here.  What the first statement says is that a SACM
environment can have Data Model A and Data Model B from different companies
as well as Data Model SACM which is the common one that we are defining.
Each of those data models needs to be complete relative to the single SACM
IM so that it does not matter which DM (of A, B or SACM) my application uses
it will be able to get all of the elements in the IM as part of a query.
 
Also, DM-002 says:
"DM-002  Data Model Structure: The data model can be structured either as
one single module or separated into modules and sub-modules that allow for
references between them.  The data model structure MAY reflect structure in
the information model, but does not need to. For example, the data model
might use one module to define endpoints, and that module might reference
other modules that describe the various assets associated with the endpoint.
Constraints and interfaces might further be defined to resolve or tolerate
ambiguity in the references (e.g. same IP address used in two separate
networks)."
 
Is this effectively reiterating that a DM must support everything in the IM,
but, that the DM can choose to break it up into submodules if they so
choose?
 
[JLS] Yes this was the intent that I understood from this.  If you are
looking at an XML schema as being the data model for Company X, it could
publish a top level schema which then allows for sub schemas for different
pieces (i.e. end-points, software, users) which are included in the top
level schema.  There is still are requirement that the entirety of the
schema be complete, but it allows for the user schema to be updated to
include additional elements that are Company X specific without having to
update the entire schema at the same time.  It would also allow for both of
the sub-schemas for users to be supported at the same time if desired.
 
Jim

Thanks,

Danny

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 22 Jun 2016 17:56:55 +0000

Thanks for the feedback Ira and Jim.  Based on your $0.04 :), I see a couple of approaches that may help things.

(1)    We could completely overhaul DM-002 such that it simply states how the relationships between information model elements MUST be maintained in the data model. By removing the text around the DM potentially being a single or multiple modules, I think we would still enable DM designers to make that decision, however, it would now be implied. I guess the question here is whether or not that is good enough?  Or, do we want a specific requirement around it?

(2)    Modify DM-002 to remove the part about "reflecting the structure of the IM" and keep it focused on the DM being able to be a single or multiple modules. Then, add a new DM requirement around maintaining the relationships between the information model elements in the data model elements.

Do either of these seem to help?

Do others, who have not weighed in yet, have thoughts on this thread?

Thanks,

Danny

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, June 21, 2016 9:30 PM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: RE: [sacm] Question about DM Requirements

Just my $0.02

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, June 21, 2016 10:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Question about DM Requirements

Then DM-001 says:

[JLS] I see no conflict here.  What the first statement says is that a SACM environment can have Data Model A and Data Model B from different companies as well as Data Model SACM which is the common one that we are defining.  Each of those data models needs to be complete relative to the single SACM IM so that it does not matter which DM (of A, B or SACM) my application uses it will be able to get all of the elements in the IM as part of a query.

Also, DM-002 says:

[JLS] Yes this was the intent that I understood from this.  If you are looking at an XML schema as being the data model for Company X, it could publish a top level schema which then allows for sub schemas for different pieces (i.e. end-points, software, users) which are included in the top level schema.  There is still are requirement that the entirety of the schema be complete, but it allows for the user schema to be updated to include additional elements that are Company X specific without having to update the entire schema at the same time.  It would also allow for both of the sub-schemas for users to be supported at the same time if desired.

Jim

Thanks,

Danny

---

From: Ira McDonald <[email-masked]>
Date: Wed, 22 Jun 2016 15:49:12 -0400

Hi Danny,

I think I prefer (2) simply because I prefer single, small requirements
(lots)
as opposed to compound requirements (which some of ours currently are,
because of their explanatory and exemplary extra sentences).

Cheers,
- Ira

On Wed, Jun 22, 2016 at 1:56 PM, Haynes, Dan <[email-masked]> wrote:

> Thanks for the feedback Ira and Jim.  Based on your $0.04 :), I see a
> couple of approaches that may help things.
>
>
>
> (1)    We could completely overhaul DM-002 such that it simply states how
> the relationships between information model elements MUST be maintained in
> the data model. By removing the text around the DM potentially being a
> single or multiple modules, I think we would still enable DM designers to
> make that decision, however, it would now be implied. I guess the question
> here is whether or not that is good enough?  Or, do we want a specific
> requirement around it?
>
>
>
> (2)    Modify DM-002 to remove the part about “reflecting the structure
> of the IM” and keep it focused on the DM being able to be a single or
> multiple modules. Then, add a new DM requirement around maintaining the
> relationships between the information model elements in the data model
> elements.
>
>
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Tuesday, June 21, 2016 9:30 PM
> *To:* Haynes, Dan <[email-masked]>; [email-masked]
> *Subject:* RE: [sacm] Question about DM Requirements
>
>
>
> Just my $0.02
>
>
>
> *From:* sacm [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Haynes, Dan
> *Sent:* Tuesday, June 21, 2016 10:54 AM
> *To:* [email-masked]
> *Subject:* [sacm] Question about DM Requirements
>
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Jun 2016 15:32:18 -0700

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Wednesday, June 22, 2016 10:57 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [sacm] Question about DM Requirements

Thanks for the feedback Ira and Jim.  Based on your $0.04 :), I see a couple
of approaches that may help things. 

[JLS] I am not sure that there is any need to change the requirements unless
you believe that the IM/DM which are being proposed as the SACM versions is
going to violate the current set of requirements.  Are you just having
problems understanding what they are saying or do you believe that there is
a violation involved?

(1)   We could completely overhaul DM-002 such that it simply states how the
relationships between information model elements MUST be maintained in the
data model. By removing the text around the DM potentially being a single or
multiple modules, I think we would still enable DM designers to make that
decision, however, it would now be implied. I guess the question here is
whether or not that is good enough?  Or, do we want a specific requirement
around it?

[JLS] It is not clear to me that we would continue to allow for a DM to be
done in pieces or not if this was removed.  We have stated explicitly that
the IM cannot be done by sub-modules (something I personally believe to be
wrong).  By default I would expect that people would believe that DMs would
need to keep this as well without explicit language.

(2)   Modify DM-002 to remove the part about "reflecting the structure of
the IM" and keep it focused on the DM being able to be a single or multiple
modules. Then, add a new DM requirement around maintaining the relationships
between the information model elements in the data model elements. 

[JLS] This makes me a bit worried.  What in the structure of the IM would
you not want to reflect into the IM?  For me the structure of the IM is the
relationships between the different elements of the IM.  I really do want
the DM to reflect that.

Thanks,

Danny

From: Jim Schaad [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2016 9:30 PM
To: Haynes, Dan <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> 
Subject: RE: [sacm] Question about DM Requirements

Just my $0.02

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, June 21, 2016 10:54 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [sacm] Question about DM Requirements

 
Then DM-001 says:

 
 
Also, DM-002 says:

 
Jim

Thanks,

Danny

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 22 Jun 2016 23:48:33 +0000

Hi Jim,

More comments inline.

Thanks,

Danny

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, June 22, 2016 6:32 PM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: RE: [sacm] Question about DM Requirements

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Wednesday, June 22, 2016 10:57 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Question about DM Requirements

Thanks for the feedback Ira and Jim.  Based on your $0.04 :), I see a couple of approaches that may help things.
[JLS] I am not sure that there is any need to change the requirements unless you believe that the IM/DM which are being proposed as the SACM versions is going to violate the current set of requirements.  Are you just having problems understanding what they are saying or do you believe that there is a violation involved?

[danny] I think it is probably more related to my confusion. My original confusion was around the way I interpreted the requirements and whether or not we could leverage multiple DMs (e.g. SWID for software, OVAL for configuration, something else for hardware, etc.) to satisfy the SACM IM. Also, whether or not that text in Section 2 conflicted with DM-001.

(1)    We could completely overhaul DM-002 such that it simply states how the relationships between information model elements MUST be maintained in the data model. By removing the text around the DM potentially being a single or multiple modules, I think we would still enable DM designers to make that decision, however, it would now be implied. I guess the question here is whether or not that is good enough?  Or, do we want a specific requirement around it?
[JLS] It is not clear to me that we would continue to allow for a DM to be done in pieces or not if this was removed.  We have stated explicitly that the IM cannot be done by sub-modules (something I personally believe to be wrong).  By default I would expect that people would believe that DMs would need to keep this as well without explicit language.

[danny] Agreed, which is why I was unsure if we needed the explicit requirement or not.  In the requirements, it also says: "IM-006 Singularity and Modularity: The SACM information model MUST be singular (i.e. there is only one information model, not multiple alternative information models from which to choose) and MAY be modular (a conjunction of several sub-components) for ease of maintenance and extension.  For example, endpoint identification could be an independent sub-component of the information model, to simplify updating of endpoint identification attributes."

Doesn't this say the IM can be made up of sub-modules :).

[JLS] This makes me a bit worried.  What in the structure of the IM would you not want to reflect into the IM?  For me the structure of the IM is the relationships between the different elements of the IM.  I really do want the DM to reflect that.

[danny] Given the text of the current requirement "The data model can be structured either as one single module or separated into modules and sub-modules...", I did not interpret "structure" to mean the relationships between the information model elements which is also adding to my confusion :).  I simply interpreted it as how the DM is implemented with respect to whether it is a single module or multiple separate modules.  With that said, I also agree that we want every DM to maintain the relationships between IM elements.

Thanks,

Danny

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, June 21, 2016 9:30 PM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Question about DM Requirements

Just my $0.02

Then DM-001 says:

Also, DM-002 says:

Jim

Thanks,

Danny