Subject: Re: [sacm] Asset Identification

From: [email-masked]
Date: Thu, 28 Mar 2013 07:11:59 -0500 (CDT)

Adam and all:

There is probably no need to split the document.

Vendors will likely use the components of AI in different ways to develop different applications.

Some vendors will not see any use for some components, but this does not mean that others cannot use them.

David Oliva

On 03/26/13, Adam Montville<[email-masked]> wrote:

I've been doing some non-SACM related work that has a need for an asset model sort of like the one in the current Asset Identification draft.  The way the Asset Identification draft is worded relegates it for use only for the purpose of identification.  I'd like to split the Asset Identification draft into at least two separate documents, where one specifies the asset model and the other which builds on the first for the purpose of asset identification.

I think such a split is advantageous in a couple of ways, but the one that stands out is having the ability to align/absorb with other efforts more easily.

Thoughts?

Adam

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

---

From: Adam Montville <[email-masked]>
Date: Thu, 28 Mar 2013 15:43:56 +0000

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 5:11 AM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Asset Identification

Adam and all:

If vendors adhere to the specification as it stands, it must only be used to identify a specific asset.  What I'm suggesting is that the base model presented in the specification could be useful in a non-asset-identifying context.  If we leave all of this in one document, then I would want to alter the specification, such that its use is not constrained to only asset identification.

David Oliva

On 03/26/13, Adam Montville<[email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

Adam

________________________________

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

---

From: David Solin <[email-masked]>
Date: Thu, 28 Mar 2013 11:59:12 -0500

Adam,

Have you looked at CIM?  The CIM asset model is used by most enterprise 
asset management products.

I've long held that AI should be specified on top of CIM -- a proven, 
widely-used standard -- instead of creating our own.  (Of course, for 
our purposes we would need the CIM schema specified in XML instead of MOF.)

Regards,
--David Solin

On 3/28/2013 7:11 AM, [email-masked] wrote:
> I've been doing some non-SACM related work that has a need for an 
> asset model sort of like the one in the current Asset Identification 
> draft.  The way the Asset Identification draft is worded relegates it 
> for use only for the purpose of identification.  I'd like to split the 
> Asset Identification draft into at least two separate documents, where 
> one specifies the asset model and the other which builds on the first 
> for the purpose of asset identification.
>
> I think such a split is advantageous in a couple of ways, but the one 
> that stands out is having the ability to align/absorb with other 
> efforts more easily.
>
> Thoughts?
>
> Adam
>
>
>
>
> ------------------------------------------------------------------------
>
> [email-masked] <mailto:[email-masked]>

-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

---

From: Adam Montville <[email-masked]>
Date: Thu, 28 Mar 2013 17:11:46 +0000

From: David Solin <[email-masked]<mailto:[email-masked]>>
Organization: jOVAL
Date: Thursday, March 28, 2013 9:59 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Asset Identification

Adam,

Have you looked at CIM?  The CIM asset model is used by most enterprise asset management products.

I have not yet looked at it.  No reason not to, so it's on my list.  If you have any pointers to spec docs, that could be helpful (only if convenient – I can search myself, of course).

I've long held that AI should be specified on top of CIM -- a proven, widely-used standard -- instead of creating our own.  (Of course, for our purposes we would need the CIM schema specified in XML instead of MOF.)

Regards,
--David Solin

On 3/28/2013 7:11 AM, [email-masked]<mailto:[email-masked]> wrote:
Adam and all:

David Oliva

On 03/26/13, Adam Montville<[email-masked]><mailto:[email-masked]> wrote:

Thoughts?

Adam

--

jOVAL.org: SCAP Simplified.
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>

---

From: Shane Shaffer <[email-masked]>
Date: Thu, 28 Mar 2013 13:54:30 -0400

If we go back well before AI, to the beginning of the efforts that would
eventually lead to the creation of AI, the folks who were working on those
efforts did consider using CIM. For specific reasons that I've lost to the
passage of time (6+ years), CIM was dismissed as not providing the needed
capabilities. Certainly along the road to AI the requirements might have
changed enough that the problematic requirements were dropped, or it may be
the case that SACM does not need the capabilities that were problematic for
CIM, but I think it is important to note that the road to AI began in part
with the rejection of CIM.

On Thu, Mar 28, 2013 at 1:11 PM, Adam Montville <[email-masked]>wrote:

>
>
>   From: David Solin <[email-masked]>
> Organization: jOVAL
> To: "[email-masked]" <[email-masked]>
>
>  I have not yet looked at it.  No reason not to, so it's on my list.  If
> you have any pointers to spec docs, that could be helpful (only if
> convenient – I can search myself, of course).
>
>
>
> widely-used standard -- instead of creating our own.  (Of course, for our
> purposes we would need the CIM schema specified in XML instead of MOF.)
>
>
>
> Regards,
> --David Solin
>
> On 03/26/13, Adam Montville<[email-masked]><[email-masked]>wrote:
>
>  I've been doing some non-SACM related work that has a need for an asset
> model sort of like the one in the current Asset Identification draft.  The
> way the Asset Identification draft is worded relegates it for use only for
> the purpose of identification.  I'd like to split the Asset Identification
> draft into at least two separate documents, where one specifies the asset
> model and the other which builds on the first for the purpose of asset
> identification.
>
> that stands out is having the ability to align/absorb with other efforts
> more easily.
>
>  Thoughts?
>
>  Adam
>
>
>
>
> ------------------------------
>
> Learn More <http://www.joval.org> | Features<http://www.joval.org/features/>|
> Download <http://www.joval.org/download/>
>
>
>
>

---

From: David Solin <[email-masked]>
Date: Thu, 28 Mar 2013 13:15:02 -0500

I'd love to understand those reasons! Several multi-billion dollar 
companies have build asset management businesses on top of CIM: IBM, 
Microsoft, HP, CA, BMC, ...

They all had do create an identification normalization layer, however.  
Perhaps that is what AI was originally for.  But as far as a data model 
for describing assets and services is concerned, CIM is the lingua 
franca of enterprise IT.

On 3/28/2013 12:54 PM, Shane Shaffer wrote:
> If we go back well before AI, to the beginning of the efforts that 
> would eventually lead to the creation of AI, the folks who were 
> working on those efforts did consider using CIM. For specific reasons 
> that I've lost to the passage of time (6+ years), CIM was dismissed as 
> not providing the needed capabilities. Certainly along the road to AI 
> the requirements might have changed enough that the problematic 
> requirements were dropped, or it may be the case that SACM does not 
> need the capabilities that were problematic for CIM, but I think it is 
> important to note that the road to AI began in part with the rejection 
> of CIM.
>
>
> On Thu, Mar 28, 2013 at 1:11 PM, Adam Montville 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     From: David Solin <[email-masked] <mailto:[email-masked]>>
>     Organization: jOVAL
>     To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>
>     I have not yet looked at it.  No reason not to, so it's on my
>     list.  If you have any pointers to spec docs, that could be
>     helpful (only if convenient – I can search myself, of course).
>
>
>
>         I've long held that AI should be specified on top of CIM -- a
>         proven, widely-used standard -- instead of creating our own. 
>         (Of course, for our purposes we would need the CIM schema
>         specified in XML instead of MOF.)
>
>
>
>         Regards,
>         --David Solin
>
>>         Some vendors will not see any use for some components, but
>>         this does not mean that others cannot use them.
>>         David Oliva
>>         I've been doing some non-SACM related work that has a need
>>         for an asset model sort of like the one in the current Asset
>>         Identification draft.  The way the Asset Identification draft
>>         is worded relegates it for use only for the purpose of
>>         identification.  I'd like to split the Asset Identification
>>         draft into at least two separate documents, where one
>>         specifies the asset model and the other which builds on the
>>         first for the purpose of asset identification.
>>
>>         I think such a split is advantageous in a couple of ways, but
>>         the one that stands out is having the ability to align/absorb
>>         with other efforts more easily.
>>
>>         Thoughts?
>>
>>         Adam
>>
>>
>>
>>

--

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 28 Mar 2013 14:21:04 -0400

You can add EMC to your list as well for CIM support already in products.

Adam - It is the Common Information Model from DMTF.

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Solin
Sent: Thursday, March 28, 2013 2:15 PM
To: Shane Shaffer
Cc: [email-masked]; Adam Montville
Subject: Re: [sacm] Asset Identification

I'd love to understand those reasons!  Several multi-billion dollar companies have build asset management businesses on top of CIM: IBM, Microsoft, HP, CA, BMC, ...

They all had do create an identification normalization layer, however.  Perhaps that is what AI was originally for.  But as far as a data model for describing assets and services is concerned, CIM is the lingua franca of enterprise IT.

On 3/28/2013 12:54 PM, Shane Shaffer wrote:
If we go back well before AI, to the beginning of the efforts that would eventually lead to the creation of AI, the folks who were working on those efforts did consider using CIM. For specific reasons that I've lost to the passage of time (6+ years), CIM was dismissed as not providing the needed capabilities. Certainly along the road to AI the requirements might have changed enough that the problematic requirements were dropped, or it may be the case that SACM does not need the capabilities that were problematic for CIM, but I think it is important to note that the road to AI began in part with the rejection of CIM.

On Thu, Mar 28, 2013 at 1:11 PM, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:

Adam,

I have not yet looked at it.  No reason not to, so it's on my list.  If you have any pointers to spec docs, that could be helpful (only if convenient - I can search myself, of course).

Regards,
--David Solin

David Oliva

Thoughts?

Adam

--

--

---

From: Ira McDonald <[email-masked]>
Date: Thu, 28 Mar 2013 14:53:56 -0400

Hi,

The CIM schema are published in both MOF and XML (machine-translated
from MOF).

  http://dmtf.org/standards/cim/cim_schema_v2350

I much prefer re-use of CIM schema for most any management standard.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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

---

From: Anton Chuvakin <[email-masked]>
Date: Thu, 28 Mar 2013 12:56:28 -0700

>   http://dmtf.org/standards/cim/cim_schema_v2350
Won't the incredibly complex nature of CIM hinder adoption of any future
SACM work?
Every time I looked at CIM schemas/docs in the last few years, all I got
was an intense headache... but then again, maybe it is just me.

-- 
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

---

From: David Solin <[email-masked]>
Date: Thu, 28 Mar 2013 15:26:56 -0500

They've got generated, annotated XSDs now?!  This should be a no-brainer!

Far from bringing complexity, this would make standardized asset 
management simplicity itself.  AI could be just a specification covering 
which CIM objects and relationships are required to minimally describe a 
computer system in the context of an ARF document.

On 3/28/2013 2:56 PM, Anton Chuvakin wrote:
>
>
> On Thu, Mar 28, 2013 at 11:53 AM, Ira McDonald 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Won't the incredibly complex nature of CIM hinder adoption of any 
> future SACM work?
> Every time I looked at CIM schemas/docs in the last few years, all I 
> got was an intense headache... but then again, maybe it is just me.
>
> -- 
> Dr. Anton Chuvakin

--

---

From: "Ronayne, James K." <[email-masked]>
Date: Thu, 28 Mar 2013 20:34:09 +0000

I found an email from 2007 that mentioned CIM and the asset data model.  It looks like it was mainly excluded because it didn't accommodate any SCAP standards data for vulnerabilities and configuration.  There was also an effort to produce a crosswalk to show the overlap between CIM, two specific vendor CMDBs, and two GOTS CMDBs.  I think there was some reluctance to include CIM because so little of it was relevant to the concerns of the time.  The asset model that was produced was much more focused.

Things have changed a lot.  We now have AI and ARF and different use cases.  We aren't trying to do as much with a single asset model.  One could envision an ARF document that uses XCCDF for benchmark results, CIM for asset attributes (another type of report), and AI to tie them together with a single identifier.  We talked about developing an asset attribute model (separate from AI) somewhat recently when we drafted a revision to the applicability specification.  In that case (it was specifically for enterprise OCIL but useful in other cases as well) we wanted the option to declare applicability of a rule or item based on attributes of an asset.  Those attributes could be technical or operational and might be stored in a CMDB, even if they aren't automatically collectable, so we could match the applicability statements with known attributes of devices.  There seemed to be general agreement among the asset working group (those that contributed to ARF, ASR, and AI) that we would want an asset attribute model and that we would first want to use things that already exist.  We might consider including as much as possible and then constraining what is mandatory to implement based on use cases.

So, I agree an asset model is useful and I think there is a clear benefit to including CIM.  I think we may want to include more than just CIM.

Jim

      Adam,

      Regards,
      --David Solin

         Adam and all:

         David Oliva

         Thoughts?

         Adam

           _____

      --

   --

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 28 Mar 2013 20:59:31 -0400

Hi,

Just to help readers understand my perspective on things, let me make you
aware that I have been doing IETF work for twenty years, mostly network
management.

I have also been an IESG member, where one of the questions to be answered
for proposed new work is whether IETF is the right organization to do this
work.

IETF and DMTF have tried to collaborate on standards before.

There is a problem that has arisen in the past due to the differences of
approach.

IETF develops standards bottom-up; DMTF tends to develop in a more top-down
manner.

Each is important, but they might be more applicable to certain
environments.

IETF is focused on the Internet, including management of network protocols.

Most of the protocols developed by IETF run on routers and switches, which
typically have limited resources.

Management, in particular, should place a small demand on internetworking
device resources.

Here is one summary of the approach used in IETF standards, in this case
defining a widely-deployed MIB module (RFC4188):

"To be consistent with IAB directives and good engineering practice,

   an explicit attempt was made to keep this MIB as simple as possible.

   This was accomplished by applying the following criteria to objects

   proposed for inclusion:

          (1)  Start with a small set of essential objects and add only

               as further objects are needed.

          (2)  Require objects be essential for either fault or

               configuration management.

          (3)  Consider evidence of current use and/or utility.

          (4)  Limit the total of objects.

          (5)  Exclude objects which are simply derivable from others in

               this or other MIBs.

          (6)  Avoid causing critical sections to be heavily

               instrumented.  The guideline that was followed is one

               counter per critical section per layer.

CIM is in wide use in large organizations. But the types of assets being
managed are not typically the focus of IETF standards.

CIM is the product of a standards development organization focused on
desktop management (DMTF).

I am seeing significant discussion of the assets within a host.

Desktops typically have significantly greater resources than internetworking
devices.

The demand to simplify the model is much less important.

My experience with the DMTF approach is succinctly summarized by your email:

"We might consider including as much as possible and then constraining what
is mandatory to implement based on use cases."

I think that kitchen-sink approach is not very consistent with the "rough
consensus and running code" bottom-up model of IETF development.

I have concerns about trying to build an IETF standard atop a DMTF standard
for this reason.

I am very aware that RFC4807 "IPsec Security Policy Database Configuration
MIB" is based on the

RFC3585 "IPsec Configuration Policy Information Model", which is based on
the DMTF Information Model for policy (PCIM and PCIMe).

The IPsec SPD-MIB was (and may still be) the largest MIB module ever
published by IETF.

I am not aware that it has been implemented by anybody, because of the size
and complexity of the model.

The company I was with at the time, which was producing policy-driven
security products, looked at the model and found it way over the top.

There were simply a tremendous number of objects that seemed totally
irrelevant, but which as a result of dependencies, needed to be implemented
to be compliant.

In a host implementation, this might be acceptable; in a router or switch,
it might be much less acceptable.

Different SDOs have different focus and different goals.

Maybe we should be asking whether IETF is the right place to do this work.

CIM might be a terrific basis for use with SACM asset identification, and
other asset use cases.

If CIM appears to be an applicable model , maybe the SACM work belongs in
DMTF, not IETF.

As an IESG member, that would have been one of my concerns.

David Harrington

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

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ronayne, James K.
Sent: Thursday, March 28, 2013 4:34 PM
To: 'David Solin'; 'Shane Shaffer'
Cc: [email-masked]'; 'Adam Montville'
Subject: Re: [sacm] Asset Identification

I found an email from 2007 that mentioned CIM and the asset data model.  It
looks like it was mainly excluded because it didn't accommodate any SCAP
standards data for vulnerabilities and configuration.  There was also an
effort to produce a crosswalk to show the overlap between CIM, two specific
vendor CMDBs, and two GOTS CMDBs.  I think there was some reluctance to
include CIM because so little of it was relevant to the concerns of the
time.  The asset model that was produced was much more focused.

Things have changed a lot.  We now have AI and ARF and different use cases.
We aren't trying to do as much with a single asset model.  One could
envision an ARF document that uses XCCDF for benchmark results, CIM for
asset attributes (another type of report), and AI to tie them together with
a single identifier.  We talked about developing an asset attribute model
(separate from AI) somewhat recently when we drafted a revision to the
applicability specification.  In that case (it was specifically for
enterprise OCIL but useful in other cases as well) we wanted the option to
declare applicability of a rule or item based on attributes of an asset.
Those attributes could be technical or operational and might be stored in a
CMDB, even if they aren't automatically collectable, so we could match the
applicability statements with known attributes of devices.  There seemed to
be general agreement among the asset working group (those that contributed
to ARF, ASR, and AI) that we would want an asset attribute model and that we
would first want to use things that already exist.  We might consider
including as much as possible and then constraining what is mandatory to
implement based on use cases.

So, I agree an asset model is useful and I think there is a clear benefit to
including CIM.  I think we may want to include more than just CIM.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Solin
Sent: Thursday, March 28, 2013 2:15 PM
To: Shane Shaffer
Cc: [email-masked]; Adam Montville
Subject: Re: [sacm] Asset Identification

They all had do create an identification normalization layer, however.
Perhaps that is what AI was originally for.  But as far as a data model for
describing assets and services is concerned, CIM is the lingua franca of
enterprise IT.

On Thu, Mar 28, 2013 at 1:11 PM, Adam Montville <[email-masked]>
wrote:

Adam,

I have not yet looked at it.  No reason not to, so it's on my list.  If you
have any pointers to spec docs, that could be helpful (only if convenient -
I can search myself, of course).

Regards,
--David Solin

Adam and all:

Vendors will likely use the components of AI in different ways to develop
different applications.

Some vendors will not see any use for some components, but this does not
mean that others cannot use them.

David Oliva

On 03/26/13, Adam Montville <mailto:[email-masked]>
<[email-masked]> wrote: 

I think such a split is advantageous in a couple of ways, but the one that
stands out is having the ability to align/absorb with other efforts more
easily.

Thoughts?

Adam

  _____  

-- 

jOVAL.org: SCAP Simplified.
 <http://www.joval.org> Learn More |  <http://www.joval.org/features/>
Features |  <http://www.joval.org/download/> Download

 

-- 

jOVAL.org: SCAP Simplified.
 <http://www.joval.org> Learn More |  <http://www.joval.org/features/>
Features |  <http://www.joval.org/download/> Download

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Mar 2013 21:56:36 -0400

>>>>> "ietfdbh" == ietfdbh  <[email-masked]> writes:
    ietfdbh> I am very aware that RFC4807 "IPsec Security Policy
    ietfdbh> Database Configuration 
    ietfdbh> MIB" is based on the

    ietfdbh> RFC3585 "IPsec Configuration Policy Information Model",
    ietfdbh> which is based on 
    ietfdbh> the DMTF Information Model for policy (PCIM and PCIMe).

    ietfdbh> The IPsec SPD-MIB was (and may still be) the largest MIB module ever
    ietfdbh> published by IETF.

It simply didn't do anything that anyone felt they actually needed. 
Hacking the SPD is simply not interesting: it's too low level.  The high
level stuff that people actually want to configure, is also a part we
couldn't agree about.

And MIBs for configuration went out of fashion.  I'd love to have time
to try IPsec configuration with yang or something,  but I don't think
that there is a market for new work.

I wanted to add to your point, but I also am skeptical when I see the
words DTMF used.  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Adam Montville <[email-masked]>
Date: Fri, 29 Mar 2013 12:08:27 +0000

Just responding to this thread to advise that I'll be unable to get back
to it until this weekend - possibly Monday.  I'm out of pocket today.
Seems to be a good discussion, even if some of it may be a rehash.

Thanks to all for the discourse!

Adam

---

From: David Solin <[email-masked]>
Date: Thu, 28 Mar 2013 11:54:55 -0500

Adam, have you looked at the asset model in CIM?