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

[Sean Turner <[e-mail]>]

On Mar 25, 2015, at 05:33, Roman D. Danyliw <[e-mail]> wrote:

> 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

Thanks, my thinking then is:

1. It seems kind of odd to force all of those folks with CPEs already to switch, i.e., it’s too onerous and frankly unlikely to happen.

2. It seems odd to force new folks to a USG site, even if it is a defacto standard in some sense, especially when there’s a “free” alternative.

3. We could do a mapping, but if there’s a away to avoid it then maybe we should.

Seems like of the options you listed below #3 or #4 with a slant towards #4, because it’s already defined, is the way to go here.

spt

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