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

["Schmidt, Charles M." <[e-mail]>]

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

> -----Original Message-----
> From: Gunnar Engelbach [mailto:[e-mail]]
> Sent: Monday, June 06, 2016 1:45 PM
> To: Schmidt, Charles M. <[e-mail]>; [e-mail];
> Michael Godsey <[e-mail]>; Jerome Athias
> <[e-mail]>
> Cc: [e-mail]; Karen O'Donoghue <[e-mail]>
> Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc
as
> a SACM WG document
> 
> 
> 
> On 6/6/2016 11:36 AM, Schmidt, Charles M. wrote:
> > 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?
> 
> 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
> 
> 
> >
> > Thanks,
> > Charles
> >
> >> -----Original Message-----
> >> From: Gunnar Engelbach [mailto:[e-mail]]
> >> Sent: Friday, May 20, 2016 1:51 PM
> >> To: Schmidt, Charles M. <[e-mail]>; [e-mail];
> >> Michael Godsey <[e-mail]>; Jerome Athias
> >> <[e-mail]>
> >> Cc: [e-mail]; Karen O'Donoghue <[e-mail]>
> >> 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