Re: [mile] Clarifying iodef:SoftwareType (Issue #47)

[Sean Turner <[e-mail]>]

Roman,

Clarifying questions:
1. Can you get a SWID for free?
2. Is there a mapping between CPE <-> SWID?

spt

On Mar 24, 2015, at 14:55, Roman D. Danyliw <[e-mail]> wrote:

> Good afternoon!
> 
> One of the remaining issues with rfc5070bis is to clarify the iodef:SoftwareType.  See Issue #47 [1].  We discussed this impasse in Honolulu [2].
> 
> --[ snip discussion from IETF 91 ]--
> Q1: (Roman Danyliw) Last mailing list discussion on clarifying iodef:Software produced no result.  What does the group want to do?
> A: (David Waltermire) Extensibility is key dimension.  Consider just using swid and reference the ISO standard.  Alternatively, redefine the class to be AdditionalData.
> A: (Adam Monteville) Reiterated the importance of extensibility
> A: Isn't swid support already in the spec?
> A: (Roman Danyliw) There is an attribute named "swid" but this comes from RFC5070 which just happened to use this name without reference to the ISO standard.
> A: (Takeshi Takahashi) IODEF-SCI can embed SWID and CPE as well, but the context is different; it is added under AdditionalData. If we need the data here, we could make a model here like the SCI draft does.
> --[ end snip ]--
> 
> The four options mentioned to date (not just at IETF 91) are:
> 
> (1) Use OVAL [3]
> 
> (2) Use swid referencing ISO/IEC 19770-2:2009 (with XML schema at [4])
> 
> (3) Don't define it and use AdditionalData
> 
> (4) Support mutiple techniques to reference software in the same way  (like IODEF-SCI and ENUM)
> 
> Approach (1) and (2) are require little further explanation.  Hence, let me describe (3) in more detail.
> 
> The thinking would be to create an IANA registry to maintain a list of external references, in this case application reference techniques (e.g., swid and CPE), just like IODEF-SCI and ENUM current do.  The class using this technique might look as follows:
>             +---------------------+
>             | Application         |
>             +---------------------+
>             | ENUM SpecID         |<>--(0..*)-[ SpecData ]
>             | STRING ext-SpecID   |
>             |                     |
>             +---------------------+
> 
> ** SpecID would map to an IANA registry of application reference techniques
> ** ext-SpecID would allow for private enumerated value extensions as currently done in the draft
> ** SpecData would be defined as follows allowing both XML or atomic data types such as a string.
>     <xs:complexType name="AppIdType" mixed="true">  
>      <xs:sequence>
>        <xs:any namespace="##any" processContents="lax"
>                minOccurs="0" maxOccurs="unbounded"/>
>      </xs:sequence>
> 
> In the same way that the general purpose ENUM approach was useful to SACM and MILE, SACM has also expressed interest in a common approach on this class too.
> 
> What does the community feel is the correct approach?
> 
> Roman
> 
> [1] http://trac.tools.ietf.org/wg/mile/trac/ticket/47
> [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-mile
> [3] https://nvd.nist.gov/cpe.cfm
> [4] http://standards.iso.org/iso/19770/-2/2009/schema.xsd
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile