Section 4.2.1 - Collector

[jimsch]

version -04

There is a collision between what is defined as a collector here and what is in the terminology draft. This draft appears to combine together both a collector and an evaluator.

Collection Task: The task by which endpoint attributes and/or
corresponding attribute values are collected

[henkbirkholz]

The Endpoint ID team's current view is that collection includes a very subtle refinement (which is why the result is considered a raw assertion and not a collection result by the majority of the team):

A collector implicitly asserts that the origin of these endpoint attributes (origin of data) is a specific target endpoint.

Personally, I would solve this small inconsistency by combining two functions (which are then basically working closely together in most cases). A collection function (there are probably multiple variants of those) that does the collection producing a collection result (which could then be preprocessed by optional functions that normalize, aggregate, correlate, etc, only in this scope) and then a very basic asserter function that prepares the data to be emitted into the SACM environment by adding the assertion that this data is about a specific target endpoint (e.g. adding or highlighting an appropriate set of identifying attributes).

[jimsch]

I will believe that a collector will explicitly assert that attributes it collects are about specific target endpoint(s). An external collector may assert attribute values for more than one target endpoint. The subtle refinement is not something that I understand. I think that if you really are doing something different that what a normal person thinks of as collection (i.e. gathering together) then you need to make some huge warnings about this and give some good examples. I can understand guidance in the sense of what to collect, although I really expect it to try and collect everything that it can, but not in terms of doing the pre-processing that is being discussed. That looks much more like some type of other function.

[sacm]

Hi,

I agree with Jim.

A Collector should simply collect (gather) anything it can from any
endpoints
it's aware of. Guidance to not collect some attributes sounds dubious to
me.

And any pre-processing or other activity beyond somple collection should
not be
part of the SACM definition of a Collector.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email protected]
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Mon, Aug 24, 2015 at 12:40 AM, Jim Schaad [email protected]
wrote:

I will believe that a collector will explicitly assert that attributes it
collects are about specific target endpoint(s). An external collector may
assert attribute values for more than one target endpoint. The subtle
refinement is not something that I understand. I think that if you really
are doing something different that what a normal person thinks of as
collection (i.e. gathering together) then you need to make some huge
warnings about this and give some good examples. I can understand guidance
in the sense of what to collect, although I really expect it to try and
collect everything that it can, but not in terms of doing the
pre-processing that is being discussed. That looks much more like some type
of other function.

—
Reply to this email directly or view it on GitHub
#30 (comment)
.

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm

[llorenzin]

LL - terminology draft does not currently have a definition of a collector
Opened issue for terminology draft to add entries for roles, role types, functions, capabilities