Subject: Re: [sacm] comments on draft-ietf-sacm-requirements-03

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 26 Feb 2015 19:52:16 +0000

Hi Dan,

Thanks for the feedback, I’m working on resolving all your comments but have a question or two,
Please see below:

From: <Romascanu>, "Dan (Dan)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 8, 2015 at 9:34 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] comments on draft-ietf-sacm-requirements-03

I apologize for the delay, here are my comments on draft-ietf-sacm-requirements-03.

I am dividing them into Technical and Editorial.

Technical

T1. In the Introduction:

Ø  Scalable and sustainable collection, expression, and evaluation of

Ø     endpoint information is foundational to SACM's objectives.  To secure

Ø     and defend a network one must reliably determine what devices are on

Ø     the network, how those devices are configured from a hardware

Ø     perspective, what software products are installed on those devices,

Ø     and how those products are configured.  We need to be able to

Ø     determine, share, and use this information in a secure, timely,

Ø     consistent, and automated manner to perform endpoint posture

Ø     assessments.

The location, the interfaces of the devices to the network, and the network topology are also factors that need to be known, understood, modelled and factored into the SACM requirements.
[NCW] Sounds reasonable.  I’ve added some new requirements that speak to needing interfaces and network topology into the general requirements.

T2. The usage of the 2119 keywords is inconsistent. One example can be found in G-001. The requirements in #1, #2, #3 seem to be at the same level – yet one is capitalized, the other two are not. I suggest a review of all keywords in the document and consistent usage, as per 2119.
[NCW] Have made a run thru all the requirements (old and new) and made an attempt to clarify them all.  Please review in the upcoming draft and let me know if I missed any.

T3. Requirement G-002 seems to me to be content free, it is equivalent to ‘we must write good standards’.
[NCW] I’m OK removing it, but wanted to make sure the group was OK with that, so for this upcoming version have left it as an editor’s note to query group…ok?

T4. G-003:  Scalability has one more dimension – what about big numbers of endpoints?
[NCW] Right, I’ve added more points of clarification to the dimension of data, topology and target endpoints.

T5. G-004: ‘Considerations for lightweight implementations of data

    models and transports is required.’ – this seems to be about downscaling. Does this mean that each SACM standard must have a ‘lightweight’ variant, or that it’s required for any SACM standard to be implemented on lightweight (resource constrained) environments?

 [NCW] I placed the requirement as a “SHOULD” as I’m not sure it is feasible to make it a MUST for all implementations and yet address scalability (especially with persistence).

T6. ARCH-002 – This requirement (if I understand it correctly) is about deployment in single or federated environments (applications, networks). Why is this called ‘Agility’?

 [NCW] Is a better word Flexibility? In that the architecture needs to be flexibility enough (I chose agility because I was thinking “nimble” or “adaptable”) to suit different deployments where there are a few participating endpoints to very large w/in an enterprise to very large requiring federation (or small requiring federation).

T7. Section 2.3 mixes requirements for data models and information models – I believe that it needs to be broken in two separate sections, one for each

[NCW] I’ve broken out the ones that are part of the operations on the data model and called that section as such.  But I’m not sure which ones would be information model specific?

T8. At IM-005 – IM-005  The data model SHOULD include management of the data,

    including data lifetime management (longevity or expiration of

    data).

What about persistence? In general I believe it’s good practice to define persistence in the IM, with specific implementation requirements in the DM

[NCW] Agreed, persistence has been added.

T9. IM-12 to IM-16 seem to me to belong more to the protocol that retrieves information from the data model than to the data model or information model

[NCW] Right, these have been moved to a section of their own.

T10. IM-19 cannot be a requirement from the data model and is a trivial requirement for the information model. Maybe the requirement tries to say something different – like different transport layers need to be supported – but then this is a again a requirement for the protocol that accesses the data model, and not for the data model

 [NCW] While I agree, I think the spirit of the requirement is to ensure that the operations on the data model could be consistent (interfaces) across the different transports.  Given that, I’m OK removing the requirement if the group agrees (I’ve added an editor’s note to that effect too).

Editorial

E1. In the Abstract:

Ø  This document defines the scope and set of requirements for the

Ø     Secure Automation and Continuous Monitoring working group.

The requirements are not ‘for the … working group’ but for the architecture, data models, protocols
[NCW] Done in next revision

E2. When talking about sections in the use case document – it would be good to provide reference (in brackets)
[NCW] Will try to do, admittedly, am not quite sure how to do the reference in XML, it is okay to just “[]” the section numbers by hand?

E3. Header error – need the name of the I-D not ‘Abbreviated Title’
[NCW] Can you help me identify where the header error is?

E4. In T-001 s/network transport/network, transport/
 [NCW] Done in next revision

I hope this helps.

Regards,

Dan