Subject: [sacm] draft-ietf-sacm-architecture-02 comments

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Jan 2015 22:10:34 -0800

Here is a first round of comments:

1.  Section 2 - not having a problem statement here but in the charter is
fine, right up to the point where the sacm group disappears and it is not
clear what working group produced the document.  

2.  Section 2 - this text currently outlines a problem, but not a problem
statement.  I would like to see some additional text added that says what
this document (or group of documents) is actually trying to do.   Thus at
the end of the first paragraph something about - We are creating a data
model that will allow for administrators to share with others and to use
data from others in a standardized method.  (is this is in this document or
should a pointer be added to the data model document?)

I think the second paragraph is going to be covered by some type of vague
protocol that allows for standardized methods of doing this, but I am not
sure that is really covered at present in the problem statements.

3.  Section 3 - I think that I have a problem with the list " collected,
processed or assessed".  There are a couple of other types of operations
that I think can be done as well.  It is possible that you think that these
are covered by those there - The operations that I would add to the list are
"exchanged and stored".  In some ways I am not sure of the difference
between processed and assessed.

4.  Section 3- I have a minor problem with the picture.  I think that a
"Repository" is a Provider and not a Controller.  (I don't know if I also
think that a "Repository" is also a consumer or not - It would depend if it
was actively looking for data or not.)  The controller plane controls access
to data but not data itself.

5.  Section 3- I would appreciate a small set of pointers or something in
this section to deal with what A, B, and C are as well.

6.  Section 3.1.1. - Is this component providing the data spontaneously
(i.e. via some type of broadcast) or is it returning the data either
synchronously or asynchronously to a request.  I cannot find this as being a
requirement in either the use cases or the requirements document.

7.  Section 3.1.1. - I am not sure what the differences is between a
collector and an aggregator.  These functions seem to be overlapping.

8. Section 3.1.1 - par 3 - I think you mean based on the former rather than
the latter.  Authorization restrictions would be based on the consumer not
the provider.

9.  Section 3.1.1 - para 5 - A Provider which is not authorized to provide
information does not seem to be a very useful concept.  I suggest deleting
"and further, be authorized to do so"  you might add to the end "and for
specific consumers"

10.  Section 3.1.2 - para 1 - s/Thus, the/The/  no implication seems to be
in place here

11.  Section 3.1.2 - para 2- what is the difference between an evaluated and
an assessed state.   Should we throw in collected states and processed
states as well (from section 3)

12.  Section 3.1.2 - para 3 - I have a real problem reading this paragraph.
I'll think about a better way to state it.

* Section 3.1.2 - I kind of expected to see text here that is similar to the
last paragraph in section 3.1.3 - A Consumer may also be a Provider.  For
example an aggregator or posture assessor that provides its results to
others.

* Section 3.1.3 - para 1 - I am having a problem with the concept of a
single controller given the breadth of the responsibilities that are being
dumped into this single component.   The functionality of "the controller"
could be spread over a number of components.

* Section 3.1.3 - Authentication -  I don't understand what the two bullets
are trying to say.   Are we saying that we do not support the use cases
where consumers may request information from a specifically identified
provider?

* Section 3.1.3 - Authorization - The bullet list does not seem to be
specific to authorization as stated.  It would seem that this is really a
new paragraph two to justify having a controller component.

* Section 3.1.3 - Authorization - Do you expect that the authorization
enforcement is going to happen in the control plane or on the provider?  The
first means that the controller needs to understand every protocol between
consumers and providers while the latter means that you need to push some
information down.  Both seem to be a problem.

* Section 3.1.3 - Authorization - Did you miss a change in the last
paragraph of this from authentication to authorization?  If not then I don't
understand the purpose of this paragraph.

* Section 3.1.3 - Identity Management - This is a nit and I don't really
expect a change - however I would expect that this would be done distributed
to some degree and must coordinated centrally - How one manages users vs
processes vs machines is often times different.

*  Section 3.1.3 - Data Store - It seems to me that it is clearer to say
that a Controller may act as a Provider rather than say it has data stores
leaving the rest of the text alone.

* Section 4- collector and evaluator should be in the terminology document
as independent terms   I should not have to get this far into the document
to find out what they are.

* Section 4 - I don't have definitions of what is the data plane.  The name
of control plane needs to be harmonized with the terminology document.

* Section 5 - I am having a problem with an information provider doing
evaluation of posture attributes.  I would have thought that this is part of
what consumers do.  This seems to say that a provider may need to pull data
from other providers

* Section 8 - message tampering is prevented by message integrity not
confidentiality.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 22 Jan 2015 15:47:11 +0100

Hello,

I cherry-picked two of those comments directly, because they touch a 
very basic topic, I think:

 > collector and an aggregator.  These functions seem to be overlapping.
[...]
 > to find out what they are.

Below is my current understanding (please correct me if I am not 
summarizing it clearly or correctly!) of how a collector, an aggregator, 
and an evaluator are related to each other. Terms that are or could be 
defined are highlighted like -this-.

At the moment, the terminology draft provides the definition of a 
-collection task- as a "process by which posture attributes or values 
are collected".

In essence, a -collector- is an -endpoint- that "has" (is "has" the 
right word?) the -capability- to execute -collection tasks-.
It acquires corresponding data about an "endpoint under assessment" 
(which is called -target endpoint- in the current draft) from the 
endpoint in question itself via:

   -internal collection- (in this case the capability to execute 
collection tasks is located on the -target endpoint- itself), or via

   -external collection- (by observing, for example, corresponding 
network traffic or "endpoint behavior". This is a distinct capability 
that is located on specific endpoints), or even by

   querying a data store (I am uncertain if this last option really 
falls under collection, semantically it is a collection).

While the definition of -collection task- states that the result is 
-Posture Assessment Information-, I think it is more generally -Endpoint 
Attributes-. Am I wrong here?

Acquired bundles of -endpoint attributes- about a -target endpoint- 
(probably produced by the capability of "being a -collector-" and the 
the result of a collection task) now can be -aggregated- and/or 
-evaluated-. These two terms are specializations of -assessed- or an 
-assessment-, IMHO (maybe only -evaluation- is?).

Between -collection- and -aggregation-/-evaluation- some intermediate 
transportation/relaying can happen (because, e.g., the capabilities are 
located on separate endpoints. This could be spelled out better later on?).

Being able to -evaluate- (actually being an -evaluator-) is defined as a 
capability in the current draft. Providing the capability of "being a 
-data store-" includes the capability to -aggregate- -endpoint 
attributes-, I think. This also could be spelled out better later on?

Overall, there is a distinct ambiguousness regarding the input & output 
of capabilities for the reader of the drafts, I think: the output of one 
capability could be the input for another (quite similar or even 
identical) capability. Additionally, there is a tad bit of inconsistency 
atm due to the drafts being in constant flux. Last but not least, the 
fact that the names of capabilities (e.g. evaluator) sound more like 
roles is a little bit confusing, isn't it?

Henk

---

From: Ira McDonald <[email-masked]>
Date: Thu, 22 Jan 2015 11:53:45 -0500

Hi Henk,

I agree with your comments on SACM currently confused terminology.

Specifically, a "capability" (by the normal English definition) should be
"collection", "evaluation", etc. (passive description of functionality in a
software component).   The related "role" is "collector", "evaluator", etc.
(active description of behavior to implement a "capability").

I'm not happy with the SACM use of the term "assessment" at all,
because it's an "eye of the beholder" sort of "capability" (i.e., there
will not be an unambiguous definition distinct from "evaluation",
IMHO).

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-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Jan 22, 2015 at 9:47 AM, Henk Birkholz <
[email-masked]> wrote:

> Hello,
>
> I cherry-picked two of those comments directly, because they touch a very
> basic topic, I think:
>
> -collection task- as a "process by which posture attributes or values are
> collected".
>
> In essence, a -collector- is an -endpoint- that "has" (is "has" the right
> word?) the -capability- to execute -collection tasks-.
> It acquires corresponding data about an "endpoint under assessment" (which
> is called -target endpoint- in the current draft) from the endpoint in
> question itself via:
>
>   -internal collection- (in this case the capability to execute collection
> tasks is located on the -target endpoint- itself), or via
>
>   -external collection- (by observing, for example, corresponding network
> traffic or "endpoint behavior". This is a distinct capability that is
> located on specific endpoints), or even by
>
>   querying a data store (I am uncertain if this last option really falls
> under collection, semantically it is a collection).
>
> (probably produced by the capability of "being a -collector-" and the the
> result of a collection task) now can be -aggregated- and/or -evaluated-.
> These two terms are specializations of -assessed- or an -assessment-, IMHO
> (maybe only -evaluation- is?).
>
> capability in the current draft. Providing the capability of "being a -data
> store-" includes the capability to -aggregate- -endpoint attributes-, I
> think. This also could be spelled out better later on?
>
>
> Overall, there is a distinct ambiguousness regarding the input & output of
> capabilities for the reader of the drafts, I think: the output of one
> capability could be the input for another (quite similar or even identical)
> capability. Additionally, there is a tad bit of inconsistency atm due to
> the drafts being in constant flux. Last but not least, the fact that the
> names of capabilities (e.g. evaluator) sound more like roles is a little
> bit confusing, isn't it?
>
>
> Henk
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 22 Jan 2015 17:50:52 -0800

So as I look at things the following things can happen:

Initial collection of raw data and conversion to a posture attribute – appears to be “collection”

Conversion of one (or more) posture attributes into a different posture attribute.  This might be as simple as renaming or changing the data format of an attribute. – no current name?

Transfer of posture attributes from one (or more) providers to another provider.  This might be done because the new provider has better capabilities or because it is collecting data from outside of its world via a proxy. – aggregation?

Comparison of one (or more) posture attributes against some type of standard and produce a new posture attribute – appears to be either an “evaluator” or an “assessment operation”

I don’t know if this list of operations is in any way complete but I think it covers most of the transformations that are being done that would end up with data being transferred from someplace back into a provider.

Jim

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Thursday, January 22, 2015 8:54 AM
To: Henk Birkholz; Ira McDonald
Cc: [email-masked]
Subject: Re: [sacm] draft-ietf-sacm-architecture-02 comments

Hi Henk,

Cheers,
- Ira

 <http://sites.google.com/site/blueroofmusic> http://sites.google.com/site/blueroofmusic
 <http://sites.google.com/site/highnorthinc> http://sites.google.com/site/highnorthinc

On Thu, Jan 22, 2015 at 9:47 AM, Henk Birkholz <[email-masked]> wrote:

Hello,

I cherry-picked two of those comments directly, because they touch a very basic topic, I think:

[...]
> to find out what they are.

Below is my current understanding (please correct me if I am not summarizing it clearly or correctly!) of how a collector, an aggregator, and an evaluator are related to each other. Terms that are or could be defined are highlighted like -this-.

At the moment, the terminology draft provides the definition of a -collection task- as a "process by which posture attributes or values are collected".

In essence, a -collector- is an -endpoint- that "has" (is "has" the right word?) the -capability- to execute -collection tasks-.
It acquires corresponding data about an "endpoint under assessment" (which is called -target endpoint- in the current draft) from the endpoint in question itself via:

  -internal collection- (in this case the capability to execute collection tasks is located on the -target endpoint- itself), or via

  -external collection- (by observing, for example, corresponding network traffic or "endpoint behavior". This is a distinct capability that is located on specific endpoints), or even by

  querying a data store (I am uncertain if this last option really falls under collection, semantically it is a collection).

While the definition of -collection task- states that the result is -Posture Assessment Information-, I think it is more generally -Endpoint Attributes-. Am I wrong here?

Acquired bundles of -endpoint attributes- about a -target endpoint- (probably produced by the capability of "being a -collector-" and the the result of a collection task) now can be -aggregated- and/or -evaluated-. These two terms are specializations of -assessed- or an -assessment-, IMHO (maybe only -evaluation- is?).

Between -collection- and -aggregation-/-evaluation- some intermediate transportation/relaying can happen (because, e.g., the capabilities are located on separate endpoints. This could be spelled out better later on?).

Being able to -evaluate- (actually being an -evaluator-) is defined as a capability in the current draft. Providing the capability of "being a -data store-" includes the capability to -aggregate- -endpoint attributes-, I think. This also could be spelled out better later on?

Overall, there is a distinct ambiguousness regarding the input & output of capabilities for the reader of the drafts, I think: the output of one capability could be the input for another (quite similar or even identical) capability. Additionally, there is a tad bit of inconsistency atm due to the drafts being in constant flux. Last but not least, the fact that the names of capabilities (e.g. evaluator) sound more like roles is a little bit confusing, isn't it?

Henk