Subject: [sacm] Possible Additional Requirements -- Collection

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 03 Jun 2014 12:36:05 -0400

Hopefully mail issues are resolved now and this won't be bounced by the 
list server...

1) Separation between collection request and collection action
   That is, the request for a data item must include enough information 
to properly identify the item to collect, but the request shall not be a 
command to directly execute nor directly applied as arguments to a command.

   The purpose of this requirement is primarily to reduce the potential 
attack vectors, but has the additional benefit of abstracting the 
request for collection from the collection method thereby allowing more 
flexibility in how collection is implemented.

2) Chaining of collected values
   The value from a collected item should be able to be used as part of 
the collection of another item.  This must be able to be expressed as 
part of the collection request so that these references can be resolved 
at the point of collection without having to interact with the requester.

   For example, using the value of a registry key to determine the 
location of an installed software package so that the proper file 
version can be collected.

Thoughts?

--gun

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 4 Jun 2014 08:51:26 -0500

On Jun 3, 2014, at 11:36 AM, Gunnar Engelbach <[email-masked]> wrote:

> 
> Hopefully mail issues are resolved now and this won't be bounced by the list server...
> 
> 
>  That is, the request for a data item must include enough information to properly identify the item to collect, but the request shall not be a command to directly execute nor directly applied as arguments to a command.
> 
>  The purpose of this requirement is primarily to reduce the potential attack vectors, but has the additional benefit of abstracting the request for collection from the collection method thereby allowing more flexibility in how collection is implemented.
> 

This seems reasonable to me.  Others?

>  The value from a collected item should be able to be used as part of the collection of another item.  This must be able to be expressed as part of the collection request so that these references can be resolved at the point of collection without having to interact with the requester.
> 
>  For example, using the value of a registry key to determine the location of an installed software package so that the proper file version can be collected.
> 

This makes sense to me as well, but I don’t prefer the word “chaining”.  To me, it makes sense to call this relationship a composition within collection requests: A collection request can be composed of other collection requests (which yield collected values).  Thoughts?

> 
> 
> Thoughts?
> 
> 
> 
> --gun
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Ira McDonald <[email-masked]>
Date: Wed, 4 Jun 2014 11:52:32 -0400

Hi,

Inline below.

Cheers,
- Ira

On Wed, Jun 4, 2014 at 9:51 AM, Adam W. Montville <[email-masked]>
wrote:

>
> On Jun 3, 2014, at 11:36 AM, Gunnar Engelbach
> <[email-masked]> wrote:
>
> >
> >  That is, the request for a data item must include enough information to
> properly identify the item to collect, but the request shall not be a
> attack vectors, but has the additional benefit of abstracting the request
> for collection from the collection method thereby allowing more flexibility
> in how collection is implemented.
> >
>
> <ira> I agree that this strong separation is an important requirement.

> the collection of another item.  This must be able to be expressed as part
> of the collection request so that these references can be resolved at the
> point of collection without having to interact with the requester.
> >
> location of an installed software package so that the proper file version
> can be collected.
> >
>
> This makes sense to me as well, but I don’t prefer the word “chaining”.
>  To me, it makes sense to call this relationship a composition within
> collection requests: A collection request can be composed of other
> collection requests (which yield collected values).  Thoughts?
>

<ira> I agree with Adam that I don't like the word "chaining" here.  I
agree with
Adam that "composition" is better.  We should avoid (in requirements) such
inter-item identity reference details as the use of a registry key.  I
think the
mechanisms of collection request "composition" should not be discussed in
a requirements or architecture document.

---

From: "Jim Bieda (jbieda)" <[email-masked]>
Date: Thu, 5 Jun 2014 03:46:54 +0000

Hi,

Also inline below.

Thanks,
Jim

From: Ira McDonald <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 4, 2014 8:52 AM
To: "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>, Ira McDonald <[email-masked]<mailto:[email-masked]>>
Cc: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Possible Additional Requirements -- Collection

Hi,

Inline below.

Cheers,
- Ira

On Wed, Jun 4, 2014 at 9:51 AM, Adam W. Montville <[email-masked]<mailto:[email-masked]>> wrote:

<Jim> I like this separation a lot.  I would potentially add a requirement for 'rate limiting' requests to prevent DOS attacks, but at the very least, we need to separate the request from the collection action.  Keep in mind that we specified that responses could be synchronous and asynchronous, so this separation is an implied requirement that's needed to support the separation of these response options.

<ira> I agree with Adam that I don't like the word "chaining" here.  I agree with
Adam that "composition" is better.  We should avoid (in requirements) such
inter-item identity reference details as the use of a registry key.  I think the
mechanisms of collection request "composition" should not be discussed in
a requirements or architecture document.

<Jim> While I think this is a reasonable requirement, I think it belongs in the data format/data definition section vs. the 'requirements' section because it specifies the internals of a request.  Maybe we should consider it a requirement for the data requests?

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

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

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 9 Jun 2014 00:02:08 +0000

Hi,

Please see below:

From: "Jim (jbieda)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 4, 2014 at 8:46 PM
To: Ira McDonald <[email-masked]<mailto:[email-masked]>>, "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>
Cc: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Possible Additional Requirements -- Collection

Hi,

Also inline below.

Thanks,
Jim

Hi,

Inline below.

Cheers,
- Ira

[NCW]  I’m OK with this as well, I think this is part of the “protocol”, so at some point, I’d like to break the requirements based on an agreed upon categorization.  But I will add this to the requirements draft.
Jim:  I like the “rate limiting” but I think that is an implementation details to be added to the state machine, so perhaps better on the architecture state machine?

[NCW] I agree that this feels more to me towards a state machine or implementation detail……