Official Release of CPE Version 2.2
|
|
|
||||||||
|
|
||||||||
|
|
|
||||||||
|
|
||||||||
|
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 |
||||||||
|
|
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 |
||||||||
|
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 |
||||||||
|
|
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 |
||||||||
|
|
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 > >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 |
||||||||
|
|
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 |
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
