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

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 6 Jun 2016 18:36:05 +0000

Hello everyone,

I wanted to do a quick loop back to the original question of this thread,
namely the adoption of
https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as a SACM
working group document. This and other threads have indicated that there is
some desire to evolve the document to address certain concerns, many of
which I hope to address in the next draft. 

With the understanding that adoption as a working group draft does not in
any way end the discussion or evolution of this draft, are there any other
thoughts regarding adoption? 

Gunnar/Tony - you both raised concerns about adoption due to the document
being exclusively focused on ISO SWID tags, but since then there appears to
be agreement to expand to other possible tag types (with the caveat that
there also appears to be consensus that this list of tags should be
constrained so that endpoints are sending content using a consistent data
model). Does this alteration address you concerns? If so, does that change
your feelings on adoption?

Thanks,
Charles 

> -----Original Message-----
> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Friday, May 20, 2016 1:51 PM
> To: Schmidt, Charles M. <[email-masked]>; [email-masked];
> Michael Godsey <[email-masked]>; Jerome Athias
> <[email-masked]>
> Cc: [email-masked]; Karen O'Donoghue <[email-masked]>
> Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc
as
> a SACM WG document
> 
> 
> Inline...
> 
> On 5/19/2016 1:27 PM, Schmidt, Charles M. wrote:
> > Tony/Gunnar,
> >
> > I agree. Details below.
> >
> >> 	Two questions not asked: who might do the
> >> 	work to bridge the gap with the gazillion other
> >> 	software identifier approaches out there, and
> >> 	whether some form of out-of-band SWID capability
> >> 	(as is used with may of the other SWID mechanisms)
> >> 	cannot be included.  For a lot of IoT stuff, it is
> >> 	essential.
> >>
> >> This right here is an excellent point.  There are other software ID
> > mechanisms
> >> out there and SWID is not going to cover everything for which there is
an
> >> alternative.
> >>
> >> Because this proposal is so SWID-specific, I can't get behind it.
> > However, if it
> >> was genericized to allow for use of current and possible future tagging
> >> mechanisms, I could certainly support that.
> > This makes sense. Even those strongly attached to the use of SWID tags
> would
> > like to make sure that this specification can handle future revisions of
the
> > ISO SWID specification, and as you both note, there are other structures
> out
> > there which people might wish to use.
> >
> > Basically, it seems to me that we want to support a common, core set of
> > functionality related to inventory and inventory events, but that we
want
> to
> > have some flexibility in the data (I'll call these "records") used to
convey
> > that information to a policy server. Are we in agreement on this? (I
don't
> > think we want the nature of what one can infer from a report to change
> based
> > on the record structure used to convey that report.)
> >
> > Given this, the following are the core capabilities of SWID M&A for
> > reporting records as I see them:
> > 1) Records need to be associated with specific instances of a specific
> > software product and version thereof.
> > --- If the same version of the same product is installed multiple times,
> > there will need to be multiple records naming the same product and
> version -
> > one associated with each actual installation. (We need to convey that a
> > given product+version is installed "exactly X times" rather than "at
least
> > one instance".)
> > --- Changes to a software product need to result in a change in the
> > associated record. (The record needs to distinguish between AcmeApp
> v1.2.3
> > and AcmeApp v1.2.4, since this is critical to multiple consumers of this
> > data.)
> > --- Records associated with a product+version need to be consistent over
> > time and across endpoints. (There needs to be an easy way for the SWID-
> PV to
> > say "this is the same product+version" across different reports and
> between
> > reports from different machines.)
> > 2) If the record is more than about 200 bytes, there needs to be a
concise
> > identifier for this record. In SWID tags, this is created by the
combination
> > of the TagCreatorRegID and the TagID fields. (Concise identifiers are
used
> > in multiple places in SWID M&A to convey information without bloating
> > messages.)
> 
> I tried to find fault, but I think as a basic core set, this is good
> coverage.
> 
> In ongoing practice there are undoubtedly going to be more capabilities
> desired for other use cases, and some tagging solutions will have useful
> capabilities that are not available in others. Extensibility is assumed.
> 
> I think it's also a necessity that a common data model be used
> regardless of the tag type/source.  For hopefully obvious reasons.
> 
> 
> 
> >
> > Do you (or anyone) have any questions or concerns about any of these
> core
> > capabilities, or have any others to add? I think all of the other SWID
M&A
> > capabilities (monitoring for changes, tracking and ordering of events,
> > subscriptions, processing targeted requests, etc.) are fairly neutral
with
> > regard to the record structure used in messages assuming the two
> > requirements above are met. Let me know if you disagree about that.
> >
> > Capabilities do not need to be inherent in the record itself. (For
example,
> > there is nothing in a SWID tag that allows one to distinguish between
> > multiple installations of a single product.) There just needs to be a
> > reliable, deterministic mechanism by which these capabilities can be met
> > while using the record.
> >
> > I will work on putting together some proposals on how different record
> types
> > can be clearly labeled in SWID M&A messages so recipients can know the
> type
> > of content they are getting prior to parsing. (Probably want a way for
> > SWID-PVs to express a preference too... need to think about this.) While
I
> > am doing that, if you have a favorite non-ISO-SWID record that you would
> > like to see supported, could you put together any necessary requirements
> > that would be needed to ensure it aligns with the core capabilities
> > described above? I think that would be very useful for fleshing out this
> > flexibility.
> >
> > I am interested in your thoughts on this. Thanks for the input.
> >
> > Charles

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 6 Jun 2016 11:45:04 -0700

> your feelings on adoption?

If there's going to be a consistent data model I don't see I reason why 
there should be any constraint on what endpoint tag types are supported.

I'd prefer to see that translation happen as soon in the lifecycle of 
the data as possible, but we'll see what consensus is on that. For 
reasons already stated, if that translation is done centrally then I 
don't SACM adoption extending much beyond a few large vendors that put 
out, effectively, their own stovepipes.

--gun

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 6 Jun 2016 19:34:37 +0000

> there should be any constraint on what endpoint tag types are supported.

I'm afraid you have lost me here. My understanding was that you were arguing
that SWID M&A should support tag types other than the ISO SWID tags. As I
understand the term, ISO SWID 2015 defines a data model, and then different
tag formats (XML, CBOR, JSON) would all be data formats of that common data
model.  But if we have completely different tag types, (for example, SWID
2015 tags and RPM records), I'm confused how there could be a common data
model that both represent. In other words, when you argued for a common data
model, to me this implicitly meant we needed to curtail the types of tags
supported to only those that could serialize that common data model.

Sorry if I am being slow here, but could you clarify how you see the tag
types relating to this common data model?

Thanks,
Charles

> Sent: Monday, June 06, 2016 1:45 PM
as

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 7 Jun 2016 21:44:23 +0000

Ok - Gunnar has set me straight.

Put in terms for the easily confused (such as myself): Gunnar was advocating
that the network messages used to convey tag data via SWID M&A employ a
standard data model so that recipients always see the same structure in the
messages and can rely on being able to parse it. With that in mind, many tag
types could be converted to this common data model used in the messages,
thus many tag types should be collected by the Posture Collector as
potential input. Gunnar - did I get it right?

In fact, this is largely what the SWID M&A specification does now. The ISO
SWID 2015 and ISO SWID 2009 specifications form a data model for SWID M&A
messages conveying tag information. However, the specification notes that
the SWID tag collection that is conveyed in these messages could come from
many "sources", some of which might be translated from different record
types. (E.g., potentially converted from package manager records or third
party inventory tool results.)

That said, based on some of the conversations that have occurred in meetings
and on list, I think there are some open questions here:
1) Currently SWID M&A uses the ISO SWID specifications as a data model.
Various parties have weighed in on the pros and cons of ISO SWID tags.
Looking from a strictly data-model perspective, what structure makes sense
for conveying tag/inventory data as the standard data model in these
messages. Personally, I would argue that the core should probably be an
existing structure - I don't see any call to invent yet another way to
describe software. 

2) As I wrote it, one of the change proposals presented to the group was
effectively to allow SWID M&A to convey any type of tag natively and simply
include a field to identify the type of tag contained in the message. This
would allow SWID M&A to convey inventory information via an unlimited number
of data models. What do people think about this given the recent
discussions? Gunnar, I take it you would be against this change and would
prefer a fixed tag format (a.k.a. data model) in the SWID M&A messages
themselves. Other thoughts?

3) With regard to conversion, I will note that some tag types (e.g., ISO
SWID tags) can be cryptographically signed. Obviously, any conversion is
going to lose those signatures. Do people think that being able to discern
correctly signed tags from other tags would be of operational significance?
If so, maybe the solution would be three types of messages: a) capture
inventory information using a single, standard data model to which all
source tags are converted [by-normalized-value], b) capture inventory
information using identifiers that can be used to reference tag structures
[by-reference], c) capture inventory information using whatever native tag
structure there is, noting that some tag types might not be consumable, but
ensuring that signatures and the like are correctly conveyed
[by-non-normalized-value]. The requesting party can indicate which of these
return methods it would like.

Any thoughts about any of these?

Thanks,
Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Schmidt, Charles
> M.
> Sent: Monday, June 06, 2016 2:35 PM
> To: Gunnar Engelbach <[email-masked]>;
> [email-masked]; Michael Godsey <[email-masked]>; Jerome
> Athias <[email-masked]>
as
> > > https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as
a
> > SACM
> > > working group document. This and other threads have indicated that
> there
> > is
> > > being exclusively focused on ISO SWID tags, but since then there
appears
> > >>> like to make sure that this specification can handle future
revisions
> of
> > >>> one associated with each actual installation. (We need to convey
that
> a

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 7 Jun 2016 15:21:43 -0700

> potential input. Gunnar - did I get it right?

Sounds like it.  But then, I thought we were understanding each other 
the last time.

...

> party inventory tool results.)

The same, I'm sure, can be said about the other tag types:  that is, 
their data models can be used to represent data from other "sources."

Taken as a given that inventing yet another software tag data model is a 
non-starter, the question then is which of the various existing models 
would be the most useful?

Most useful, in this case, would to me involve three primary factors:

1) 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).

2) Capable of being easily extended to cover gaps as necessary. Possibly 
as a fork and not part of its normal maintenance.

3) Readily accessible (for example, the spec is not behind a paywall).

> themselves. Other thoughts?

Yup, I'm all for a single common tag format for SACM.  But it also needs 
to be one that can be extended to accommodate future needs -- for 
instance, adding in data items available in other tag types that the 
common model does not have an allowance for.

Other options:

i.  Minimize the amount of data items covered by the common data model 
and include the original tag as an "attachment," thus preserving all 
data that it represents.

ii.  We allow that an OOB mechanism can exist, providing enough 
information with the common tag such that the original can be retrieved 
if that's what the processor really needs.

---

From: Adam Montville <[email-masked]>
Date: Thu, 9 Jun 2016 14:47:47 -0500

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 <[email-masked]> 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/ <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 9 Jun 2016 17:33:03 -0400

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
>
>> On May 17, 2016, at 11:21 AM, Karen O'Donoghue <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Folks,
>>
>> As discussed during our last couple of meetings, this is the official 
>> call for adoption of 
>> a SACM working group document.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Thu, 9 Jun 2016 18:57:27 -0500

Tony,

This working group has, on several occasions, reached out formally to other standards development organizations very early on in our work, and I believe you are well aware of such facts.

I don’t believe we’re ignoring anything or being insular or making preposterous statements, but I am pleased to see that you like the adopted solution.

Kind regards,

Adam

> On Jun 9, 2016, at 4:33 PM, Tony Rutkowski <[email-masked]> wrote:
> 
> Hi Adam,
> 
>>> On May 17, 2016, at 11:21 AM, Karen O'Donoghue <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> Folks,
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 9 Jun 2016 20:04:58 -0400

Adam,

I don't buy the "group has...reached out."   That's like
the ITU-T game of sending out "liaison statements"
to other groups asking for their reactions to
some work item.   You have to task someone to
go look at all the many pointers that have been
provided - do the research and analysis and
incorporate their solutions in what you are doing.
Try breaking out of your walls of insularity.

--tony

On 2016-06-09 7:57 PM, Adam Montville wrote:
> This working group has, on several occasions, reached out formally to 
> other standards development organizations very early on in our work, 
> and I believe you are well aware of such facts.
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 9 Jun 2016 17:44:52 -0700

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:
>> 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].
>>
>>> As discussed during our last couple of meetings, this is the 
>>> official call for adoption of

---

From: Adam Montville <[email-masked]>
Date: Fri, 10 Jun 2016 06:24:46 -0500

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 <[email-masked]> 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
> 
>   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 May 17, 2016, at 11:21 AM, Karen O'Donoghue <[email-masked] <mailto:[email-masked]>> 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/>https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ <https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/> as a SACM working group document.
>>>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Jun 2016 14:12:02 +0000

Re: Requirements - is this not what https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ is about? Maybe it needs an update.

Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Friday, June 10, 2016 2:25 PM
To: Gunnar Engelbach
Cc: <[email-masked]>; [email-masked]
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

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 <[email-masked]<mailto:[email-masked]>> wrote:

--gun

--tony

Kind regards,

Adam & Karen

On May 17, 2016, at 11:21 AM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> 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.

Thanks,
Karen and Adam
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

sacm mailing list

[email-masked]<mailto:[email-masked]>

sacm mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 14 Jun 2016 19:01:51 +0000

Hi Gunnar,

Thanks for the suggestions. I agree with these requirements with a possible
tweak on number 3: I would say that the data model needs to cover a
sufficent "core", but probably does not need to explicitly cover every piece
of information from every reasonable, providing that the extensibility
features described in item 1 would allow that information to be captured.
The end result is the same - the transmitted data can capture all
information from whatever source is used without loss. The difference is
that we only need to identify fields that are likely to be of common
utility, and edge cases can naturally be taken care of through extensions.

Does this seem reasonable?

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
> Sent: Thursday, June 09, 2016 7:45 PM
> To: [email-masked]; Adam Montville <[email-masked]>;
> <[email-masked]> <[email-masked]>
as
> a SACM WG document
> 
> 
> 
> 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.
> 
best
> from among those that are good enough.  If any.
> 
really
> only have three:
necessary, to be
> sure it continues to meet SACM needs without relying on the good graces of
> the current owner
> 
>   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)
> 
> 
chime in.
> However, I think the simpler and more informal we can keep this list the
> quicker we can grind through it.
> 
> 
> --gun
> 
> 
> 
> 
> 
> 		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
> 
> 		[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
> <[email-masked] <mailto:[email-masked]> > 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/>
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
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 14 Jun 2016 12:53:17 -0700

Yes, that's exactly what I had in mind.  Ideally there would be enough 
coverage right off the bat such that we don't have to do any extensions 
right away -- and the fewer down the road the better.

All three of these requirements are linked.  I would say that 
extensibility is primary, but that needs to be weighed against how easy 
it is to extend, which depends on the owning organization and might be 
offset by starting with a data model that is already very complete for 
our needs.  And so on.

The trickier part to start with is figuring out what we mean by 
complete.  What is that set of properties and data types that are core?  
I would prefer to build such a list by looking at usage -- current and 
desired.  A simpler approach would be to look at existing data models 
and flag things we think are important, but that can be self-fulfilling 
and insular.

--gun

---

From: Adam Montville <[email-masked]>
Date: Sat, 18 Jun 2016 07:38:30 -0500

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) <[email-masked]> wrote:
> 
> Re: Requirements – is this not what https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/> is about? Maybe it needs an update.
> 
> Regards,
> 
> Dan
> 
> 
> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Adam Montville
> Cc: <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Jun 9, 2016, at 7:44 PM, Gunnar Engelbach <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Sat, 18 Jun 2016 10:06:15 -0700

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
> 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).
>
> 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) <[email-masked] 
>> <mailto:[email-masked]>> 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:[email-masked]]*On Behalf Of*Adam Montville
>> *Sent:*Friday, June 10, 2016 2:25 PM
>> *To:*Gunnar Engelbach
>> *Cc:*<[email-masked] <mailto:[email-masked]>>;[email-masked] 
>> <mailto:[email-masked]>
>> *Subject:*Re: [sacm] Call for adoption of 
>> draft-coffin-sacm-nea-swid-patnc as a SACM WG document
>> 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
>>     <[email-masked]
>>     <mailto:[email-masked]>> 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.
>>
>>     necessary, to be sure it continues to meet SACM needs without
>>     relying on the good graces of the current owner
>>
>>       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
>>
>>
>>
>>             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
>>             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
>>             Charles and Gunnar will hold the pen.
>>
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>                 Folks,
>>                 As discussed during our last couple of meetings, this
>>                 Please reply with any comments or concerns along your
>>                 support of this action to the mailing list.
>>                 Thanks,
>>                 Karen and Adam

---

From: "Haynes, Dan" <[email-masked]>
Date: Mon, 20 Jun 2016 18:24:26 +0000

Hi Adam,

This all makes sense to me.  With regards to completeness, I would also add DM-001 which says “The data model MUST contain a data model element for each information model element”.  As long as we make our IM complete, our DM will also be complete because of this requirement.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Saturday, June 18, 2016 8:39 AM
To: Dan (Dan) Romascanu <[email-masked]>
Cc: Gunnar Engelbach <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

1) Extensibility

Thoughts?

Adam

On Jun 13, 2016, at 9:12 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

Re: Requirements – is this not what https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ is about? Maybe it needs an update.

Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Friday, June 10, 2016 2:25 PM
To: Gunnar Engelbach
Cc: <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

--gun

--tony

Kind regards,

Adam & Karen

Folks,

Thanks,
Karen and Adam

sacm mailing list

sacm mailing list

---

From: Adam Montville <[email-masked]>
Date: Mon, 20 Jun 2016 18:49:12 -0500

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 <[email-masked]> wrote:
> 
> 
> 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 Jun 13, 2016, at 9:12 AM, Romascanu, Dan (Dan) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Re: Requirements – is this not what  <https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/>https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/> is about? Maybe it needs an update.
>>> 
>>> Regards,
>>> 
>>> Dan
>>> 
>>> 
>>> Cc: < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>;  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>> On Jun 9, 2016, at 7:44 PM, Gunnar Engelbach < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>> On May 17, 2016, at 11:21 AM, Karen O'Donoghue < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Folks,
>>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 21 Jun 2016 07:57:49 -0700

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 
>>> we’re talking about doing when it comes to selecting a data model 
>>> for software identification:
>>>
>>> 1) Extensibility
>>> 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) 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>> *Cc:*<[email-masked]>;[email-masked]
>>>> 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.
>>>>
>>>>     <[email-masked]> 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.
>>>>
>>>>     efforts which is the best from among those that are good
>>>>     enough.  If any.
>>>>
>>>>       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
>>>>
>>>>     shoe-horning data into fields that weren't really meant for
>>>>     that type of data)
>>>>
>>>>
>>>>     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
>>>>
>>>>
>>>>
>>>>             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
>>>>             Because the topic of software identification, and SWID
>>>>             in particular, appears to be a contentious one, we are
>>>>             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
>>>>                 <[email-masked]> wrote:
>>>>                 Folks,
>>>>                 this is the official call for adoption of