Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

[Gunnar Engelbach <[e-mail]>]

Nah.

The conversation recently about software tags has been about translating 
the various software tags into a common data model where that data model 
is, preferably, one of the existing software tags.

But that would mean having a data model for endpoint attributes and a 
separate data model for software tags.  As long as the tag information 
is going to be translated I don't see why it should use a data model 
that is different than that used for other endpoint attributes.


--gun



On 6/20/2016 4:49 PM, Adam Montville wrote:
> Hi Gun,
>
> I’m going to go out on a limb and say I’m not tracking.  Are you 
> referring to Mike’s inquiry about data formats?  If so, I’m not sure 
> that thread is talking about data models as much as it is talking 
> about specific formats (i.e. JSON, XML, CBOR, etc.).
>
> I agree with you that software identify information is “just a set of 
> endpoint attributes”, but I’m not sure that we’re treating it any 
> differently.  Can you explain?
>
> Adam
>
>
>> On Jun 18, 2016, at 12:06 PM, Gunnar Engelbach 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>> While we're on the topic,
>>
>> There is an effort in progress to determine a data model for SACM 
>> endpoint collection.  Software identity information is just a set of 
>> endpoint attributes.  So is there a reason why software identity is 
>> treated differently?
>>
>>
>> --gun
>>
>>
>> On 6/18/2016 5:38 AM, Adam Montville wrote:
>>> Hi.  Because we would like to move our requirements through IESG, I 
>>> would like to drive this to ground. There are three things that 
>>> we’re talking about doing when it comes to selecting a data model 
>>> for software identification:
>>>
>>> 1) Extensibility
>>> 2) Accessibility (not cost prohibitive)
>>> 3) Completeness
>>>
>>> There is a data model requirement for (1) - DM-014 Attribute 
>>> Extensibility.  There does not seem to be a requirement for 
>>> accessibility (2) or completeness (3).
>>>
>>> My question is this: Do we need such requirements?
>>>
>>> I would assert that we do not.  Accessibility is something that we 
>>> will always judge by virtue of the fact that we operate within the 
>>> culture of the IETF.  Completeness is not something we need to put 
>>> into the requirements draft by virtue of DM-002 Data Model 
>>> Structure, which indicates that a data model can be structured 
>>> monolithically or composed of modules/sub-modules—this seems to 
>>> imply that we could be ok with “completeness” potentially coming 
>>> from more than one place.
>>>
>>> Thoughts?
>>>
>>> Adam
>>>
>>>
>>>> On Jun 13, 2016, at 9:12 AM, Romascanu, Dan (Dan) 
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>> Re: Requirements – is this not 
>>>> whathttps://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/is 
>>>> about? Maybe it needs an update.
>>>> Regards,
>>>> Dan
>>>> *From:*sacm [mailto:[e-mail]]*On Behalf Of*Adam Montville
>>>> *Sent:*Friday, June 10, 2016 2:25 PM
>>>> *To:*Gunnar Engelbach
>>>> *Cc:*<[e-mail]>;[e-mail]
>>>> *Subject:*Re: [sacm] Call for adoption of 
>>>> draft-coffin-sacm-nea-swid-patnc as a SACM WG document
>>>> This seems like a fine approach.
>>>> As part of that third item, I’d like to get requirements from our 
>>>> own drafts as well, starting perhaps with the vulnerability 
>>>> scenario, but also considering our requirements and other drafts.
>>>>
>>>>     On Jun 9, 2016, at 7:44 PM, Gunnar Engelbach
>>>>     <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>>     Hey Tony, funny thing that you should say that.  You seem to
>>>>     have a better awareness of the other efforts going on out there
>>>>     than I do, so I could use your help in identifying other good
>>>>     candidates and what will be necessary to support as many of
>>>>     them as possible.
>>>>
>>>>     What I'd really like to do is take a more formal approach --
>>>>     gather some requirements and then see from among the existing
>>>>     efforts which is the best from among those that are good
>>>>     enough.  If any.
>>>>
>>>>     But first is a matter of setting the requirements. Stated
>>>>     generally, I really only have three:
>>>>
>>>>       1)  Is extensible -- as a fork outside of the current owner,
>>>>     if necessary, to be sure it continues to meet SACM needs
>>>>     without relying on the good graces of the current owner
>>>>
>>>>       2)  Readily accessible (eg., spec is not cost prohibitive for
>>>>     any users)
>>>>
>>>>       3)  The most complete (that is, closest to being able to
>>>>     represent the other tag types without loss of data or
>>>>     shoe-horning data into fields that weren't really meant for
>>>>     that type of data)
>>>>
>>>>
>>>>     I'm sure Charles, et al, will have other requirements, so feel
>>>>     free to chime in. However, I think the simpler and more
>>>>     informal we can keep this list the quicker we can grind through it.
>>>>
>>>>
>>>>     --gun
>>>>
>>>>
>>>>
>>>>     On 6/9/2016 2:33 PM, Tony Rutkowski wrote:
>>>>
>>>>         Hi Adam,
>>>>
>>>>         A good solution.  Charles and Gunnar should also engage
>>>>         in some proactive outreach. Simply stating that "no other
>>>>         solutions to the problem of software identification have
>>>>         been submitted" is preposterous when there are so many
>>>>         out there.  IMHO, one of the long-standing problems with
>>>>         SACM is its institutional and participatory insularity in an
>>>>         arena where so many almost identical activities are occurring
>>>>         in other venues where there is far greater industry
>>>>         participation.
>>>>         Ignoring them diminishes the value of whatever SACM
>>>>         accomplishes.
>>>>
>>>>         --tony
>>>>
>>>>         On 2016-06-09 3:47 PM, Adam Montville wrote:
>>>>
>>>>             All:
>>>>             After several on-list discussions, the last virtual
>>>>             interim, and the discussions surrounding this call for
>>>>             adoption, the chairs acknowledge that there are some
>>>>             key concerns with this draft, but also see that there
>>>>             is rough consensus for adoption.  We additionally note
>>>>             that no other solutions to the problem of software
>>>>             identification have been submitted to the working group
>>>>             [1].
>>>>             Because the topic of software identification, and SWID
>>>>             in particular, appears to be a contentious one, we are
>>>>             designating Charles Schmidt and Gunnar Engelbach as
>>>>             editors of the working group draft [2].  We believe
>>>>             that Charles and Gunnar will bring the necessary
>>>>             balance to this draft, so that the key concerns are
>>>>             sufficiently addressed.
>>>>             Kind regards,
>>>>             Adam & Karen
>>>>             [1] This draft adoption does not preclude future
>>>>             alternative submissions
>>>>             [2] Note that original authors will remain authors, but
>>>>             Charles and Gunnar will hold the pen.
>>>>
>>>>                 On May 17, 2016, at 11:21 AM, Karen O'Donoghue
>>>>                 <[e-mail]> wrote:
>>>>                 Folks,
>>>>                 As discussed during our last couple of meetings,
>>>>                 this is the official call for adoption of
>>>>                 https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as
>>>>                 a SACM working group document.
>>>>                 Please reply with any comments or concerns along
>>>>                 your support of this action to the mailing list.
>>>>                 Thanks,
>>>>                 Karen and Adam
>>>>                 _______________________________________________
>>>>                 sacm mailing list
>>>>                 [e-mail] <mailto:[e-mail]>
>>>>                 https://www.ietf.org/mailman/listinfo/sacm
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             _______________________________________________
>>>>
>>>>             sacm mailing list
>>>>
>>>>             [e-mail] <mailto:[e-mail]>
>>>>
>>>>             https://www.ietf.org/mailman/listinfo/sacm
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>
>>>>         sacm mailing list
>>>>
>>>>         [e-mail] <mailto:[e-mail]>
>>>>
>>>>         https://www.ietf.org/mailman/listinfo/sacm
>>>>
>>>> _______________________________________________
>>>> sacm mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
>>
>