Official Release of CPE Version 2.2

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Official Release of CPE Version 2.2

Andrew Buttner
Administrator
I am pleased to announce the Official Release of CPE Version 2.2.  This was a minor update that clarified a few outstanding issues with the previous specification.  The exact changes are listed below:

* clarify what term to use for an initial release
* clarify vendor component regarding no qualified DNS
* move paragraph about consulting the dictionary

For a copy of the new specification, please visit the CPE Web site at:

http://cpe.mitre.org/specification/index.html

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Official Release of CPE Version 2.2

Waltermire, David A.
Drew,

I noticed in the updated cpe-dictionary_2.2.xsd that you changed the import
of the http://www.w3.org/XML/1998/namespace namespace to reference a
relative file.  This breaks XML tools if the xml.xsd file is not present.
Could you please change it to use the schemaLocation=
"http://www.w3.org/2001/xml.xsd".

Thank you,

Dave

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, March 11, 2009 9:47 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Official Release of CPE Version 2.2

I am pleased to announce the Official Release of CPE Version 2.2.  This was
a minor update that clarified a few outstanding issues with the previous
specification.  The exact changes are listed below:

* clarify what term to use for an initial release
* clarify vendor component regarding no qualified DNS
* move paragraph about consulting the dictionary

For a copy of the new specification, please visit the CPE Web site at:

http://cpe.mitre.org/specification/index.html

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Official Release of CPE Version 2.2

Andrew Buttner
Administrator
Thank you Dave for pointing this out.  The error is in the dictionary schema file as it does not reflect the schema as defined in the spec.  I have reposted the correct schema file.  Note that there is no change to the spec.

Again, sorry for the confusion.

Thanks
Drew

>-----Original Message-----
>From: David Waltermire [mailto:[hidden email]]
>Sent: Thursday, March 12, 2009 6:31 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Official Release of CPE Version 2.2
>
>Drew,
>
>I noticed in the updated cpe-dictionary_2.2.xsd that you changed the
>import
>of the http://www.w3.org/XML/1998/namespace namespace to reference a
>relative file.  This breaks XML tools if the xml.xsd file is not
>present.
>Could you please change it to use the schemaLocation=
>"http://www.w3.org/2001/xml.xsd".
>
>Thank you,
>
>Dave
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, March 11, 2009 9:47 PM
>To: [hidden email]
>Subject: [CPE-DISCUSSION-LIST] Official Release of CPE Version 2.2
>
>I am pleased to announce the Official Release of CPE Version 2.2.  This
>was
>a minor update that clarified a few outstanding issues with the previous
>specification.  The exact changes are listed below:
>
>* clarify what term to use for an initial release
>* clarify vendor component regarding no qualified DNS
>* move paragraph about consulting the dictionary
>
>For a copy of the new specification, please visit the CPE Web site at:
>
>http://cpe.mitre.org/specification/index.html
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Official Release of CPE Version 2.2

rdefuria
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Drew, folks,

I compared "official-cpe-dictionary_v2.1.xml" to
"official-cpe-dictionary_v2.2.xml" via winmerge; I notice no differences
to any <cpe-item> elements.

That is, the only changes are:

- - the addition of
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

- - <schema_version> and <timestamp> were updated


Is this correct?


- -Rich DeFuria

- --
Rich DeFuria  <[hidden email]>
Belarc, Inc.  <http://www.belarc.com/>
"IT Management for the Internet Age"




> -----Original Message-----
> From: Buttner, Drew [mailto:[hidden email]]
> Sent: Thursday, March 12, 2009 8:59 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Official Release of CPE Version
> 2.2
>
> Thank you Dave for pointing this out.  The error is in the
> dictionary schema file as it does not reflect the schema as defined
> in the spec.  I have reposted the correct schema file.  Note that
> there is no change to the spec.
>
> Again, sorry for the confusion.
>
> Thanks
> Drew
>
> >-----Original Message-----
> >From: David Waltermire [mailto:[hidden email]]
> >Sent: Thursday, March 12, 2009 6:31 PM
> >To: cpe-discussion-list CPE Community Forum
> >Subject: Re: [CPE-DISCUSSION-LIST] Official Release of CPE Version
> 2.2
> >
> >Drew,
> >
> >I noticed in the updated cpe-dictionary_2.2.xsd that you changed
> the
> >import
> >of the http://www.w3.org/XML/1998/namespace namespace to reference
> a
> >relative file.  This breaks XML tools if the xml.xsd file is not
> >present.
> >Could you please change it to use the schemaLocation=
> >"http://www.w3.org/2001/xml.xsd".
> >
> >Thank you,
> >
> >Dave
> >
> >-----Original Message-----
> >From: Buttner, Drew [mailto:[hidden email]]
> >Sent: Wednesday, March 11, 2009 9:47 PM
> >To: [hidden email]
> >Subject: [CPE-DISCUSSION-LIST] Official Release of CPE Version 2.2
> >
> >I am pleased to announce the Official Release of CPE Version 2.2.
> This
> >was
> >a minor update that clarified a few outstanding issues with the
> previous
> >specification.  The exact changes are listed below:
> >
> >* clarify what term to use for an initial release
> >* clarify vendor component regarding no qualified DNS
> >* move paragraph about consulting the dictionary
> >
> >For a copy of the new specification, please visit the CPE Web site
> at:
> >
> >http://cpe.mitre.org/specification/index.html
> >
> >Thanks
> >Drew
> >
> >---------
> >
> >Andrew Buttner
> >The MITRE Corporation
> >[hidden email]
> >781-271-3515
>



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.3 (Build 4028)
Charset: us-ascii

wj8DBQFJvj+A/jfZczYbnHURAmPMAJ94YStp7hvmXViBTbc3QNWLeJ9FMwCfTJGL
EBcSMEvqLCZV5JEd+lz3gQc=
=HbMi
-----END PGP SIGNATURE-----
--
RDeFuria
rich@belarc.com
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision

Wolfkiel, Joseph
Not much out on the list this week, so I thought I'd get a few thoughts
before bugging out for the weekend.

1.  I'm not sure everyone has been fully updated on the discussions NIST,
MITRE, NSA, DHS and DISA have been having about how to get CPE performing as
a fully functional enumeration and as a set of data exchange standards.

After much thought (you saw the research paper MITRE put together earlier),
we've come to a common belief that managing CPE names should be a separate
activity from building exchange standards, establishing matching algorithms,
and hanging additional metadata from named software products.

Some of the posts Drew has been making over the last couple of weeks have
been at my request to expand the discussion out to the CPE community so we
could either get buy-in, or learn about reasons why this may or may not be a
good idea as we look at transitioning to CPE 3.0 sometime in the next year.

You may have noticed some frustration on my part that the conversations
turned more to the technologies we could use versus the core discussions of
what CPE should really be and how we could independently manage CPE names
and still look forward to the possible metadata we can associate with named
products and how different vendor products can share algorithms or
associations.

The feedback I'd really like to get is some level of agreement that managing
lists of names (to include text strings, titles in different languages, and
legal associations between component names) of software products should be a
separate activity from defining transmission, matching, and metadata
standards.

I'd like to pare the core CPE standard down to just a consensus set of
agreements on what parts of a software product name constitute the core CPE
"enumeration" and what metadata should be tagged to CPE names separately.
Potentially, this process would look like the CVE process, where CVE IDs are
submitted to MITRE, QA'd, then submitted to NIST where they are associated
with other metadata in the NVD, which is publicly available.

2.  That said, I am suggesting that the submission of CPE names be separated
from the exchange of CPE identifiers between SCAP tools.  I'm attaching two
schemas that I would suggest serve as the basis for those two use cases.
The CPE-S schema is intended to serve as a way for CPE content contributors
to associate basic metadata with software names, such as different language
titles, suggested deprecations, etc.  The CPE-X schema is intended to be a
light weight exchange that could replace the URI as a way to share CPE names
between tools.  Again, I like the idea of going with tagged values for CPE
name components (elements or attributes is negotiable--more later) and
assuming the common body of knowledge can be made available to everyone
through the NIST CPE dictionary.

I'll stop there since it's time to go home.

Again, I'm soliciting input on the vision for separating CPE into separate
efforts -- One for maintaining names and relationships between name
components, and some TBD others to work through exchange standards and
common sharing of logical relationships between names and associations of
other metadata that can be associated with names from the enumeration.
(okay, I really couldn't stop)


Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


CPE Exchange Schema UML 20 Mar 09.jpg (31K) Download Attachment
CPE Submission Schema UML 20 Mar 09.jpg (106K) Download Attachment
cpe-s.xsd (11K) Download Attachment
cpe-x.xsd (3K) Download Attachment
smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision

Andrew Buttner
Administrator
Sorry for the length of this reply, but there was a lot of good stuff to
address in the original email ...


>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Friday, March 20, 2009 5:58 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision

...

>After much thought (you saw the research paper MITRE put together
>earlier), we've come to a common belief that managing CPE names
>should be a separate activity from building exchange standards,
>establishing matching algorithms, and hanging additional metadata
>from named software products.

I am in agreement that we need to simplify the current CPE Specification.
The idea of the CPE Language is an important one, but its inclusion in the
CPE Spec distracts from the enumeration.  In addition, the hanging of
additional metadata is something best left to an outside source (e.g. NVD)

Matching is also a candidate for something to be split out although this is
a little less definitive.  Currently matching is tightly coupled with the
name format.  If we continue down this path, then I think matching needs to
stay with the spec.  But if we decouple the name from matching, then I could
see how this could be broken out into something separate.

What do others in the community think about simplifying the current
specification?  Would this be a positive step forward for us?




>The feedback I'd really like to get is some level of agreement that
>managing lists of names (to include text strings, titles in different
>languages, and legal associations between component names) of
>software products should be a separate activity from defining
>transmission, matching, and metadata standards.

I think this is where the DoD vision can be married with the research work
ongoing in the semantic web.  I would like to ask the community the
following question:

Did CPE choose to enumerate at too complex a level?  What I mean is that
should CPE have chosen to enumerate simpler components like VENDOR, SOFTWARE
PRODUCT, and FUNCTIONAL TYPE (i.e. operating system or web server)?  In
actuality we made the choice to enumerate at a higher level that involved
many different components and the relationships between these components may
be too complex.

If we back down a level, and enumerate the individual vendors, and the
individual software products, then these terms can become the foundation of
a semantic web implementation.  This would enable others outside of the
enumeration to associate information with the terms and start to infer
associations between each other.




>I'd like to pare the core CPE standard down to just a consensus set of
>agreements on what parts of a software product name constitute the core
>CPE "enumeration" and what metadata should be tagged to CPE names
>separately.

I think this is the biggest decision we have.  If we focus our enumeration
on the individual components, then I don't see benefit of enumerating all
the possible version strings, or all the known edition strings.  These
components seem better suited as tags and as information associated with a
given software product term.

Would CPE be useful if it just enumerated the known software products (i.e.
Red Hat Enterprise Linux) and left the version and edition information to
some other resource (ontology?) to make the association?




>Potentially, this process would look like the CVE process,
>where CVE IDs are submitted to MITRE, QA'd, then submitted to NIST
>where they are associated with other metadata in the NVD, which is
>publicly available.

I could see this type of relationship working well for CPE.  Of course,
others could also leverage the simplified enumeration and associate even
more metadata with the VENDOR and SOFTWARE PRODUCT terms.



If you have made it this far, then I sincerely thank you for your time!

Thanks
Drew


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision (U)

Smith, Robert J Mr NII/DoD-CIO
UNCLASSIFIED

I made it to the end!  Good Information!


I Applaud the work you are doing with the CPE data dictionary and hope you
continue developing the CPE with vendor domain name, software product
titles, and  version numbers.  I support the DoD Enterprise Software
Initiative (ESI) as their PM for IT Asset Management and I am encouraging
our Components to use your CPE Data Dictionary as a starting point for
standardized software titles that have gone through a vetting and approval
process.

The commercial vendors involved in IT asset management and auto discovery
tools seem to have their own (proprietary) naming conventions for software
titles.  I hope as part of your vetting process that the commercial vendors
are invited to participate and share their best practices and lessons
learned or simply why they choose to use a certain title name.  All the
vendors I've talked to seem to provide the ability to add additional
software titles.  

Matching should not be split out.  It provides a wealth of information when
aggregating like data/licenses and looking at historical records
for trend analysis. I also think you're A/H/O approach is a good one and
should remain as part of the specification.


R/
Bob

(703) 601-4729 ext 124





-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, March 31, 2009 8:49 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision

Sorry for the length of this reply, but there was a lot of good stuff to
address in the original email ...


>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Friday, March 20, 2009 5:58 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision

...

>After much thought (you saw the research paper MITRE put together
>earlier), we've come to a common belief that managing CPE names should
>be a separate activity from building exchange standards, establishing
>matching algorithms, and hanging additional metadata from named
>software products.

I am in agreement that we need to simplify the current CPE Specification.
The idea of the CPE Language is an important one, but its inclusion in the
CPE Spec distracts from the enumeration.  In addition, the hanging of
additional metadata is something best left to an outside source (e.g. NVD)

Matching is also a candidate for something to be split out although this is
a little less definitive.  Currently matching is tightly coupled with the
name format.  If we continue down this path, then I think matching needs to
stay with the spec.  But if we decouple the name from matching, then I could
see how this could be broken out into something separate.

What do others in the community think about simplifying the current
specification?  Would this be a positive step forward for us?




>The feedback I'd really like to get is some level of agreement that
>managing lists of names (to include text strings, titles in different
>languages, and legal associations between component names) of software
>products should be a separate activity from defining transmission,
>matching, and metadata standards.

I think this is where the DoD vision can be married with the research work
ongoing in the semantic web.  I would like to ask the community the
following question:

Did CPE choose to enumerate at too complex a level?  What I mean is that
should CPE have chosen to enumerate simpler components like VENDOR, SOFTWARE
PRODUCT, and FUNCTIONAL TYPE (i.e. operating system or web server)?  In
actuality we made the choice to enumerate at a higher level that involved
many different components and the relationships between these components may
be too complex.

If we back down a level, and enumerate the individual vendors, and the
individual software products, then these terms can become the foundation of
a semantic web implementation.  This would enable others outside of the
enumeration to associate information with the terms and start to infer
associations between each other.




>I'd like to pare the core CPE standard down to just a consensus set of
>agreements on what parts of a software product name constitute the core
>CPE "enumeration" and what metadata should be tagged to CPE names
>separately.

I think this is the biggest decision we have.  If we focus our enumeration
on the individual components, then I don't see benefit of enumerating all
the possible version strings, or all the known edition strings.  These
components seem better suited as tags and as information associated with a
given software product term.

Would CPE be useful if it just enumerated the known software products (i.e.
Red Hat Enterprise Linux) and left the version and edition information to
some other resource (ontology?) to make the association?




>Potentially, this process would look like the CVE process, where CVE
>IDs are submitted to MITRE, QA'd, then submitted to NIST where they are
>associated with other metadata in the NVD, which is publicly available.

I could see this type of relationship working well for CPE.  Of course,
others could also leverage the simplified enumeration and associate even
more metadata with the VENDOR and SOFTWARE PRODUCT terms.



If you have made it this far, then I sincerely thank you for your time!

Thanks
Drew


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision (U)

Andrew Buttner
Administrator
Bob,

Can you explain to the list how you see your project using the Official CPE
Dictionary?  You mention standardized software titles ... are you using the
<title> to synch with commercial vendor output?  Are you using the CPE Name
in any capacity?  Knowing how you are using CPE will help us all better
understand where CPE needs to go in the future.

Commercial vendors, government agencies, individual experts are all
encouraged to participate in these discussions and their input is extremely
valuable.

Thanks
Drew


>-----Original Message-----
>From: Smith, Robert J Mr NII/DoD-CIO [mailto:[hidden email]]
>Sent: Wednesday, April 01, 2009 9:58 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)
>
>UNCLASSIFIED
>
>I made it to the end!  Good Information!
>
>
>I Applaud the work you are doing with the CPE data dictionary and hope
>you
>continue developing the CPE with vendor domain name, software product
>titles, and  version numbers.  I support the DoD Enterprise Software
>Initiative (ESI) as their PM for IT Asset Management and I am
>encouraging
>our Components to use your CPE Data Dictionary as a starting point for
>standardized software titles that have gone through a vetting and
>approval
>process.
>
>The commercial vendors involved in IT asset management and auto
>discovery
>tools seem to have their own (proprietary) naming conventions for
>software
>titles.  I hope as part of your vetting process that the commercial
>vendors
>are invited to participate and share their best practices and lessons
>learned or simply why they choose to use a certain title name.  All the
>vendors I've talked to seem to provide the ability to add additional
>software titles.
>
>Matching should not be split out.  It provides a wealth of information
>when
>aggregating like data/licenses and looking at historical records
>for trend analysis. I also think you're A/H/O approach is a good one and
>should remain as part of the specification.
>
>
>R/
>Bob
>
>(703) 601-4729 ext 124
>
>
>
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Tuesday, March 31, 2009 8:49 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>
>Sorry for the length of this reply, but there was a lot of good stuff to
>address in the original email ...
>
>
>>-----Original Message-----
>>From: Wolfkiel, Joseph [mailto:[hidden email]]
>>Sent: Friday, March 20, 2009 5:58 PM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>
>...
>
>>After much thought (you saw the research paper MITRE put together
>>earlier), we've come to a common belief that managing CPE names should
>>be a separate activity from building exchange standards, establishing
>>matching algorithms, and hanging additional metadata from named
>>software products.
>
>I am in agreement that we need to simplify the current CPE
>Specification.
>The idea of the CPE Language is an important one, but its inclusion in
>the
>CPE Spec distracts from the enumeration.  In addition, the hanging of
>additional metadata is something best left to an outside source (e.g.
>NVD)
>
>Matching is also a candidate for something to be split out although this
>is
>a little less definitive.  Currently matching is tightly coupled with
>the
>name format.  If we continue down this path, then I think matching needs
>to
>stay with the spec.  But if we decouple the name from matching, then I
>could
>see how this could be broken out into something separate.
>
>What do others in the community think about simplifying the current
>specification?  Would this be a positive step forward for us?
>
>
>
>
>>The feedback I'd really like to get is some level of agreement that
>>managing lists of names (to include text strings, titles in different
>>languages, and legal associations between component names) of software
>>products should be a separate activity from defining transmission,
>>matching, and metadata standards.
>
>I think this is where the DoD vision can be married with the research
>work
>ongoing in the semantic web.  I would like to ask the community the
>following question:
>
>Did CPE choose to enumerate at too complex a level?  What I mean is that
>should CPE have chosen to enumerate simpler components like VENDOR,
>SOFTWARE
>PRODUCT, and FUNCTIONAL TYPE (i.e. operating system or web server)?  In
>actuality we made the choice to enumerate at a higher level that
>involved
>many different components and the relationships between these components
>may
>be too complex.
>
>If we back down a level, and enumerate the individual vendors, and the
>individual software products, then these terms can become the foundation
>of
>a semantic web implementation.  This would enable others outside of the
>enumeration to associate information with the terms and start to infer
>associations between each other.
>
>
>
>
>>I'd like to pare the core CPE standard down to just a consensus set of
>>agreements on what parts of a software product name constitute the core
>>CPE "enumeration" and what metadata should be tagged to CPE names
>>separately.
>
>I think this is the biggest decision we have.  If we focus our
>enumeration
>on the individual components, then I don't see benefit of enumerating
>all
>the possible version strings, or all the known edition strings.  These
>components seem better suited as tags and as information associated with
>a
>given software product term.
>
>Would CPE be useful if it just enumerated the known software products
>(i.e.
>Red Hat Enterprise Linux) and left the version and edition information
>to
>some other resource (ontology?) to make the association?
>
>
>
>
>>Potentially, this process would look like the CVE process, where CVE
>>IDs are submitted to MITRE, QA'd, then submitted to NIST where they are
>>associated with other metadata in the NVD, which is publicly available.
>
>I could see this type of relationship working well for CPE.  Of course,
>others could also leverage the simplified enumeration and associate even
>more metadata with the VENDOR and SOFTWARE PRODUCT terms.
>
>
>
>If you have made it this far, then I sincerely thank you for your time!
>
>Thanks
>Drew


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision (U)

Smith, Robert J Mr NII/DoD-CIO
UNCLASSIFIED

Drew,

I am encouraging the DoD Components to use the CPE data dictionary software
titles as the standard naming convention to be used within their own IT
Asset Management systems. The DoD ITAM IPT is looking at collecting IT asset
data that is aggregated at the Component level.  The data will be used to
identify strategic sourcing opportunities, to conduct trend analysis, reuse
opportunities, and to identify compliance issues.  It is my understanding
that a lot of the commercial discovery and asset management tools can add
additional titles or import standard names used by their customers.  If we
can get everyone to standardize on a single data dictionary source then the
aggregation of data would be easier and more meaningful to the end user or
unanticipated user.  


R/
Bob

(703) 601-4729 ext 124

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, April 01, 2009 12:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)

Bob,

Can you explain to the list how you see your project using the Official CPE
Dictionary?  You mention standardized software titles ... are you using the
<title> to synch with commercial vendor output?  Are you using the CPE Name
in any capacity?  Knowing how you are using CPE will help us all better
understand where CPE needs to go in the future.

Commercial vendors, government agencies, individual experts are all
encouraged to participate in these discussions and their input is extremely
valuable.

Thanks
Drew


>-----Original Message-----
>From: Smith, Robert J Mr NII/DoD-CIO [mailto:[hidden email]]
>Sent: Wednesday, April 01, 2009 9:58 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)
>
>UNCLASSIFIED
>
>I made it to the end!  Good Information!
>
>
>I Applaud the work you are doing with the CPE data dictionary and hope
>you continue developing the CPE with vendor domain name, software
>product titles, and  version numbers.  I support the DoD Enterprise
>Software Initiative (ESI) as their PM for IT Asset Management and I am
>encouraging our Components to use your CPE Data Dictionary as a
>starting point for standardized software titles that have gone through
>a vetting and approval process.
>
>The commercial vendors involved in IT asset management and auto
>discovery tools seem to have their own (proprietary) naming conventions
>for software titles.  I hope as part of your vetting process that the
>commercial vendors are invited to participate and share their best
>practices and lessons learned or simply why they choose to use a
>certain title name.  All the vendors I've talked to seem to provide the
>ability to add additional software titles.
>
>Matching should not be split out.  It provides a wealth of information
>when aggregating like data/licenses and looking at historical records
>for trend analysis. I also think you're A/H/O approach is a good one
>and should remain as part of the specification.
>
>
>R/
>Bob
>
>(703) 601-4729 ext 124
>
>
>
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Tuesday, March 31, 2009 8:49 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>
>Sorry for the length of this reply, but there was a lot of good stuff
>to address in the original email ...
>
>
>>-----Original Message-----
>>From: Wolfkiel, Joseph [mailto:[hidden email]]
>>Sent: Friday, March 20, 2009 5:58 PM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>
>...
>
>>After much thought (you saw the research paper MITRE put together
>>earlier), we've come to a common belief that managing CPE names should
>>be a separate activity from building exchange standards, establishing
>>matching algorithms, and hanging additional metadata from named
>>software products.
>
>I am in agreement that we need to simplify the current CPE
>Specification.
>The idea of the CPE Language is an important one, but its inclusion in
>the CPE Spec distracts from the enumeration.  In addition, the hanging
>of additional metadata is something best left to an outside source
>(e.g.
>NVD)
>
>Matching is also a candidate for something to be split out although
>this is a little less definitive.  Currently matching is tightly
>coupled with the name format.  If we continue down this path, then I
>think matching needs to stay with the spec.  But if we decouple the
>name from matching, then I could see how this could be broken out into
>something separate.
>
>What do others in the community think about simplifying the current
>specification?  Would this be a positive step forward for us?
>
>
>
>
>>The feedback I'd really like to get is some level of agreement that
>>managing lists of names (to include text strings, titles in different
>>languages, and legal associations between component names) of software
>>products should be a separate activity from defining transmission,
>>matching, and metadata standards.
>
>I think this is where the DoD vision can be married with the research
>work ongoing in the semantic web.  I would like to ask the community
>the following question:
>
>Did CPE choose to enumerate at too complex a level?  What I mean is
>that should CPE have chosen to enumerate simpler components like
>VENDOR, SOFTWARE PRODUCT, and FUNCTIONAL TYPE (i.e. operating system or
>web server)?  In actuality we made the choice to enumerate at a higher
>level that involved many different components and the relationships
>between these components may be too complex.
>
>If we back down a level, and enumerate the individual vendors, and the
>individual software products, then these terms can become the
>foundation of a semantic web implementation.  This would enable others
>outside of the enumeration to associate information with the terms and
>start to infer associations between each other.
>
>
>
>
>>I'd like to pare the core CPE standard down to just a consensus set of
>>agreements on what parts of a software product name constitute the
>>core CPE "enumeration" and what metadata should be tagged to CPE names
>>separately.
>
>I think this is the biggest decision we have.  If we focus our
>enumeration on the individual components, then I don't see benefit of
>enumerating all the possible version strings, or all the known edition
>strings.  These components seem better suited as tags and as
>information associated with a given software product term.
>
>Would CPE be useful if it just enumerated the known software products
>(i.e.
>Red Hat Enterprise Linux) and left the version and edition information
>to some other resource (ontology?) to make the association?
>
>
>
>
>>Potentially, this process would look like the CVE process, where CVE
>>IDs are submitted to MITRE, QA'd, then submitted to NIST where they
>>are associated with other metadata in the NVD, which is publicly
available.

>
>I could see this type of relationship working well for CPE.  Of course,
>others could also leverage the simplified enumeration and associate
>even more metadata with the VENDOR and SOFTWARE PRODUCT terms.
>
>
>
>If you have made it this far, then I sincerely thank you for your time!
>
>Thanks
>Drew


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Vision (U)

Andrew Buttner
Administrator
Thank you for sharing this.  I'm sure I speak for the community  when I say
we are excited for what you are trying to do.

Thanks
Drew

>-----Original Message-----
>From: Smith, Robert J Mr NII/DoD-CIO [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 12:05 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)
>
>UNCLASSIFIED
>
>Drew,
>
>I am encouraging the DoD Components to use the CPE data dictionary
>software
>titles as the standard naming convention to be used within their own IT
>Asset Management systems. The DoD ITAM IPT is looking at collecting IT
>asset
>data that is aggregated at the Component level.  The data will be used
>to
>identify strategic sourcing opportunities, to conduct trend analysis,
>reuse
>opportunities, and to identify compliance issues.  It is my
>understanding
>that a lot of the commercial discovery and asset management tools can
>add
>additional titles or import standard names used by their customers.  If
>we
>can get everyone to standardize on a single data dictionary source then
>the
>aggregation of data would be easier and more meaningful to the end user
>or
>unanticipated user.
>
>
>R/
>Bob
>
>(703) 601-4729 ext 124
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, April 01, 2009 12:24 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)
>
>Bob,
>
>Can you explain to the list how you see your project using the Official
>CPE
>Dictionary?  You mention standardized software titles ... are you using
>the
><title> to synch with commercial vendor output?  Are you using the CPE
>Name
>in any capacity?  Knowing how you are using CPE will help us all better
>understand where CPE needs to go in the future.
>
>Commercial vendors, government agencies, individual experts are all
>encouraged to participate in these discussions and their input is
>extremely
>valuable.
>
>Thanks
>Drew
>
>
>>-----Original Message-----
>>From: Smith, Robert J Mr NII/DoD-CIO [mailto:[hidden email]]
>>Sent: Wednesday, April 01, 2009 9:58 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision (U)
>>
>>UNCLASSIFIED
>>
>>I made it to the end!  Good Information!
>>
>>
>>I Applaud the work you are doing with the CPE data dictionary and hope
>>you continue developing the CPE with vendor domain name, software
>>product titles, and  version numbers.  I support the DoD Enterprise
>>Software Initiative (ESI) as their PM for IT Asset Management and I am
>>encouraging our Components to use your CPE Data Dictionary as a
>>starting point for standardized software titles that have gone through
>>a vetting and approval process.
>>
>>The commercial vendors involved in IT asset management and auto
>>discovery tools seem to have their own (proprietary) naming conventions
>>for software titles.  I hope as part of your vetting process that the
>>commercial vendors are invited to participate and share their best
>>practices and lessons learned or simply why they choose to use a
>>certain title name.  All the vendors I've talked to seem to provide the
>>ability to add additional software titles.
>>
>>Matching should not be split out.  It provides a wealth of information
>>when aggregating like data/licenses and looking at historical records
>>for trend analysis. I also think you're A/H/O approach is a good one
>>and should remain as part of the specification.
>>
>>
>>R/
>>Bob
>>
>>(703) 601-4729 ext 124
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Tuesday, March 31, 2009 8:49 PM
>>To: [hidden email]
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>>
>>Sorry for the length of this reply, but there was a lot of good stuff
>>to address in the original email ...
>>
>>
>>>-----Original Message-----
>>>From: Wolfkiel, Joseph [mailto:[hidden email]]
>>>Sent: Friday, March 20, 2009 5:58 PM
>>>To: cpe-discussion-list CPE Community Forum
>>>Subject: Re: [CPE-DISCUSSION-LIST] CPE Vision
>>
>>...
>>
>>>After much thought (you saw the research paper MITRE put together
>>>earlier), we've come to a common belief that managing CPE names should
>>>be a separate activity from building exchange standards, establishing
>>>matching algorithms, and hanging additional metadata from named
>>>software products.
>>
>>I am in agreement that we need to simplify the current CPE
>>Specification.
>>The idea of the CPE Language is an important one, but its inclusion in
>>the CPE Spec distracts from the enumeration.  In addition, the hanging
>>of additional metadata is something best left to an outside source
>>(e.g.
>>NVD)
>>
>>Matching is also a candidate for something to be split out although
>>this is a little less definitive.  Currently matching is tightly
>>coupled with the name format.  If we continue down this path, then I
>>think matching needs to stay with the spec.  But if we decouple the
>>name from matching, then I could see how this could be broken out into
>>something separate.
>>
>>What do others in the community think about simplifying the current
>>specification?  Would this be a positive step forward for us?
>>
>>
>>
>>
>>>The feedback I'd really like to get is some level of agreement that
>>>managing lists of names (to include text strings, titles in different
>>>languages, and legal associations between component names) of software
>>>products should be a separate activity from defining transmission,
>>>matching, and metadata standards.
>>
>>I think this is where the DoD vision can be married with the research
>>work ongoing in the semantic web.  I would like to ask the community
>>the following question:
>>
>>Did CPE choose to enumerate at too complex a level?  What I mean is
>>that should CPE have chosen to enumerate simpler components like
>>VENDOR, SOFTWARE PRODUCT, and FUNCTIONAL TYPE (i.e. operating system or
>>web server)?  In actuality we made the choice to enumerate at a higher
>>level that involved many different components and the relationships
>>between these components may be too complex.
>>
>>If we back down a level, and enumerate the individual vendors, and the
>>individual software products, then these terms can become the
>>foundation of a semantic web implementation.  This would enable others
>>outside of the enumeration to associate information with the terms and
>>start to infer associations between each other.
>>
>>
>>
>>
>>>I'd like to pare the core CPE standard down to just a consensus set of
>>>agreements on what parts of a software product name constitute the
>>>core CPE "enumeration" and what metadata should be tagged to CPE names
>>>separately.
>>
>>I think this is the biggest decision we have.  If we focus our
>>enumeration on the individual components, then I don't see benefit of
>>enumerating all the possible version strings, or all the known edition
>>strings.  These components seem better suited as tags and as
>>information associated with a given software product term.
>>
>>Would CPE be useful if it just enumerated the known software products
>>(i.e.
>>Red Hat Enterprise Linux) and left the version and edition information
>>to some other resource (ontology?) to make the association?
>>
>>
>>
>>
>>>Potentially, this process would look like the CVE process, where CVE
>>>IDs are submitted to MITRE, QA'd, then submitted to NIST where they
>>>are associated with other metadata in the NVD, which is publicly
>available.
>>
>>I could see this type of relationship working well for CPE.  Of course,
>>others could also leverage the simplified enumeration and associate
>>even more metadata with the VENDOR and SOFTWARE PRODUCT terms.
>>
>>
>>
>>If you have made it this far, then I sincerely thank you for your time!
>>
>>Thanks
>>Drew


smime.p7s (4K) Download Attachment