Subject: [sacm] comments and answers on draft-ietf-sacm-use-cases-05

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Dec 2013 13:54:51 +0000

Here are a few comments on draft-ietf-sacm-use-cases-05, as well as answers to part of the questions the editors implanted in the text. 

Editorial comments: 

1. The first paragraph in the Introduction needs to be either dropped or reformulated without using the 'we' language. We need to have in mind the reader of the RFC a few years from now for which the stages of the process we followed will have little relevance. 

2. The latest editorial changes are not reflected yet in the introduction sections. For example the split of some of the use cases under usage scenarios

3. 'Content' is widely used in the document. In some cases it looks like it means configuration information, in other places status, in other places policies or any combination of the above. There is a need for clarification and in some cases of differentiation. Maybe it should be part of the definitions in the terminology I-D

Answers to some of the QUESTIONS asked in text: 

1. QUESTION: Since this is about security automation, can we drop
          the User and just use Application?  Is there a better term to
          use here?  Once the policy is selected, the rest seems like
          something we definitely would want to automate, so I dropped
          the User part.

I believe that dropping the User part was the right decision. 

2. QUESTION: It was suggested that mentioning several common
              acquisition methods, such as local API, WMI, Puppet, DCOM,
              SNMP, CMDB query, and NEA, without forcing any specific
              method would be good.  I have concerns this could devolve
              into a "what about my favorite?" contest.  OTOH, the
              charter does specifically call for use of existing
              standards where applicable, so the use cases document
              might be a good neutral location for such information, and
              might force us to consider what types of external
              interfaces we might need to support when we consider the
              requirements.  It appears that the generic workflow
              sequence would be a good place to mention such common
              acquisition methods.

I prefer remaining at the higher level here. We can mention that it is recommended to used standard acquisition methods, but it is too early for a list and we risk to fall in the rathole of 'my preferred method is missing' unless we make the list so long that it becomes irrelevant. Listing and sorting acquisition methods should be left for a later stage. 

3. QUESTION: Evaluator generates a report or log or
              notification of some type?

I believe that it typically does. The question is whether the log and/or notification are part of the posture assessment. I am not sure. 

4.     QUESTION: Is it just the type?  Or is it to identify what
         endpoint instances to target for assessment using metadata such
         as the endpoint's organizationally expected type (e.g.,
         expected function/role, etc.)

What is 'type'? We may miss a definition here. I thought that type is actually the organizationally expected function/role, maybe also version. 

5.  QUESTION: Are we missing a building block that determines what
   previously collected data, if any, is suitable for evaluation and
   what data needs to be actually collected?

Probably yes, taking into account usage scenations like 2.2.2, 2.2.3 which rely on historical data. 

Thanks and Regards,

Dan
(speaking as contributor)