One of my follow-up actions was to address the description of products in the CSAF JSON format. Until now, I've avoided defining the schema for this problem, because the JSON mapping enables some approaches that are harder to implement in XML. I wrote something up about this in a
previous email (May 8).
A snippet of a CVRF XML instance looks like this:
  <Branch Name="Cisco" Type="Vendor">
   <Branch Name="IOS" Type="Product Name">
    <Branch Name="12.2SE" Type="Product Version">
     <Branch Name="12.2(55)SE" Type="Service Pack">
      <FullProductName ProductID="CVRFPID-103763">Cisco IOS 12.2SE 12.2(55)SE</FullProductName>
     </Branch>
     <Branch Name="12.2(55)SE3" Type="Service Pack">
      <FullProductName ProductID="CVRFPID-105394">Cisco IOS 12.2SE 12.2(55)SE3</FullProductName>
     </Branch>
     <Branch Name="12.2(55)SE2" Type="Service Pack">
      <FullProductName ProductID="CVRFPID-105689">Cisco IOS 12.2SE 12.2(55)SE2</FullProductName>
     </Branch>
     ....
The above defines three products:ÂCVRFPID-103763,ÂCVRFPID-105394, andÂCVRFPID-105689.
Each of these products has associated a "full product name", a "service pack", a "product name", a "product version", and a "vendor". The CVRF specification identifies additional attributes that can be defined in the "branches", however those attributes are not strictly hierarchical - architecture, host name, language, legacy, product family. This makes fitting them into the above structure awkward, at best.
The underlying goal here is to associate a bunch of property values with a given product ID. In the most verbose form, the JSON form of the product definition for "CVRFPID-103763 " could just be:
{
 "id": "CVRFPID-103763",
 "full_name": "Cisco IOS 12.2SE 12.2(55)SE",
 "service_pack": "12.2(55)SE",
 "version": "12.2SE",
 "name": "IOS",
 "vendor": "Cisco"
}
(Note that I removed "product" from attribute names, so instead of "product_name" it is just "name".)
Keeping with the data model of CVRF, additional properties to allow here would include "architecture", "host_name", "language", "legacy", "product_family", "specification". Of course, we've also been talking about how to identify products uniquely, so "cpe", "swid", and "spdx" are good candidates for properties here as well. And of course, since it is JSON, we can allow for arbitrary vendor extensions here. So far, the proposed JSON definition of a product is a significant improvement over the XML of CVRF, because it has an obvious approach for extensibility, eliminates the arbitrary taxonomy for attributes that don't fit a taxonomy, and allows for multiple different software identity mechanisms.
While the above form is explicit and flexible, it is also quite verbose. How do we eliminate the verbosity? Proposal is to allow for the definition of a "set" of attributes that can then be reused. A definition of a set of attributes for the above examples in XML:
{
 "id": "ios-12.2SE",
 "vendor": "Cisco",
 "name" : "IOS",
 "version": "12.2SE"
}
The above defines three attributes that can be reused in association with a product definition
Being able to combine attribute sets will further reduce duplication. So the full proposal is to allow "union" of attribute sets:
{
 "id": "ios",
 "vendor": "Cisco",
 "name": "IOS",
},
{
 "id": "ios-12.2SE",
 "union" : "ios", // this means share properties "vendor" is Cisco, name is "IOS".
 "version": "12.2SE"
}
Restating the original XML product descriptions using attribute sets:
product_descriptions: [
 {
  "attribute_set": "ios-12.2SE",
  "products": [
   {
    "id": "CVRFPID-103763",
    "full_name": "Cisco IOS 12.2SE 12.2(55)SE",
    "service_pack": "12.2(55)SE",
   },
   {
    "id": "CVRFPID-105394",
    "full_name": "Cisco IOS 12.2SE 12.2(55)SE3",
    "service_pack": "12.2(55)SE3",
   },
   {
    "id": "CVRFPID-105689",
    "full_name": "Cisco IOS 12.2SE 12.2(55)SE2",
    "service_pack": "12.2(55)SE2",
   },
 },
 {
  "attribute_set": "ios-12.2EX",
  "products": [
   ...
  ]
 }
]
For discussion at our meeting tomorrow: Any objection to me changing the product tree in JSON to match what I describe above?
Further enhancement ideas:
- "id" attribute is optional, if only one of swid, cpe, or spdx is provided, then the value of the one present is used as the "id".
- full_name - it strikes me that this field could be completely optional. The default might simply be to take the space-separated concatenation of the available attributes (excluding "id").
Eric.