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

[Jerome Athias <[e-mail]>]

Hi

(4) seems the best approach IMHO for now (would allow use of OVAL/CPE,
SWID, or any others. And the "any others" is needed.)

Warning regarding OVAL vs IODEF-SCI (4.5.2.) for the -Platform-
definition and use: different
Little warning regarding "Application" vs "Software"

Note: a IANA registry tentative would be difficult, IMHO, and not
flexible enough (potentially too restrictive) IF the extension
mechanism is not allowing others (e.g. own organisation
classification/categories). Furthermore, I'm not sure a IANA registry
with just 2 entries would need effort put in it. Cristal clear
recommandations/guidances for use of CPE or SWID could be enough.

(2) is not free
Any stats on real/current usage rate of SWID?

PS: SWID->CPE mapping is possible

My 2c for now
Best regards


2015-03-24 20:55 GMT+01:00 Roman D. Danyliw <[e-mail]>:
> 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