Open jimsch opened 9 years ago
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).
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.
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 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: blueroofmusic@gmail.com 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 notifications@github.com 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 https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/30#issuecomment-134031599 .
sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm
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
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