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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 8 Jan 2015 17:34:51 +0000

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.

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.

T3. Requirement G-002 seems to me to be content free, it is equivalent to 'we must write good standards'.

T4. G-003:  Scalability has one more dimension - what about big numbers of 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?

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'?

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

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

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

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

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

E2. When talking about sections in the use case document - it would be good to provide reference (in brackets)

E3. Header error - need the name of the I-D not 'Abbreviated Title'

E4. In T-001 s/network transport/network, transport/

I hope this helps.

Regards,

Dan