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

[Gunnar Engelbach <[e-mail]>]

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] <mailto:[e-mail]>>;[e-mail] 
>> <mailto:[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]
>>     <mailto:[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] <mailto:[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
>