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

["Roman D. Danyliw" <[e-mail]>]

Hello Sean!

Response inline ...

> On Mar 24, 2015, at 6:31 PM, Sean Turner <[e-mail]> wrote:
> 
> Roman,
> 
> Clarifying questions:
> 1. Can you get a SWID for free?

Yes.

> 2. Is there a mapping between CPE <-> SWID?

There isn't one of which I am aware. Does anyone know differently?

Roman

> 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
>