Subject: Re: [sacm] Asset Identification

From: Adam Montville <[email-masked]>
Date: Mon, 1 Apr 2013 12:24:15 +0000

I hope everyone had a relaxing weekend.

I'd like to level-set this thread.  I had proposed taking the asset
hierarchy out of asset identification for the sake of future work, but
without really knowing whether it would be useful that way.

I'd like to constrain this discussion to that specific issue.

We have an need to 1) classify assets, 2) identify assets.

Classifying Assets: We need to have some way to express an asset taxonomy
and that taxonomy needs to include anything of value to an organization,
which may include facilities, technology/hardware, physical items (i.e.
documentation), digital items, and people.  The Asset Identification
specification does this today, and my proposal was to separate this from
the spec for reuse at other times (I.e. when CPE or a similar spec doesn't
work).

Identify Assets: We need to have some way to identify a specific instance
of an asset class which, again, needs to include anything of value to an
organization (as per above).  The Asset Identification specification does
this today, and this would remain as part of the "Asset Identification"
draft proper.  

Whether we allow extensibility for CIM, SCIM, another spec/standard, is a
different question.

>From my perspective, the plan of record is to move forward improving the
NIST-version of Asset Identification, while ensuring suitable points of
extensibility.  I'd like to see *identification* succinct, contained, but
extensible, while the taxonomy is the pivot between different worlds.

Adam

On 3/29/13 4:08 AM, "Adam Montville" <[email-masked]> wrote:

>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
>
>
>
>On 3/28/13 8:56 PM, "Michael Richardson" <[email-masked]> wrote:
>
>>
>>>>>>> "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
>>   [ 
>>	
>>
>
>
>
>
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: David Solin <[email-masked]>
Date: Mon, 01 Apr 2013 11:21:54 -0500

That's very sensible, Adam; I agree.

-- 

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