[sacm] review of draft-ietf-sacm-use-cases-00

["David Harrington" <[e-mail]>]

Hi,

I have reviewed the current revision (posted by my co-author DW ;-) and have
some comments and questions.

--------------- Technical:
4.1.5 How are we going to handle virtual endpoints and virtual resources,
such as virtual disks, that are allocated dynamically?

4.1.5	In the [Todo:], what if a human sets a value into a field that can
then be retrieved programmatically, such as a user's department,
	Or the departmental owner of a device? Would that make it no longer
metadata, but data collection?
	Where is the "machine" category you mention?

4.1.6 This section should also include discussion of 
	a) endpoints  that can have multiple identifiers of the same type,
such as IP addresses on a router or mac addresses on a switch.
	b) endpoints whose identifiers can change over time, such as
DHCP-assigned addresses.
	c) identifiers that can represent multiple endpoints, such as hosts
in a server farm behind a NAT or load balancer.
	d) identifiers that are unique within an administrative domain, but
not globally unique (such as 192.168.x.x or 10.x.x.x addresses)

4.1.6 Can we write this section as a use case?

4.1.4, 4.1.5, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5
I am having difficulty understanding how this text describes use cases; it
looks more like a wish list of requirements.
Can we rewrite these as use cases? 
Or should we move them into the requirements doc? 
(but shouldn't the requirements be supported by documented use cases? Rather
than the other way round?)

4.2.1 there are a number of terms used here that I don't recognize, such as
configuration scoring and control catalog mapping. Can we get these defined
in the text, or the terminology document?
Some terms need definition to avoid ambiguity, such as configuration
metadata.

4.2.6 As virtual entities (e.g. virtual disks) are created that map to
physical resources (such as disks), asset management will probably need to
understand those mappings, and security automation will need to understand
the security posture of the physical resources to assess the security
posture of the virtual resource.

4.2.7 The configuration of network interfaces would seem to be part of
security posture assessment for an endpoint. Many RFCs deal with configuring
network interfaces, and there is a reason why security considerations are
included - so operators can assess the potential security issues surrounding
various protocols. That sounds to me like it would be in scope.

4.3 I suppose we should add something about changes to users and departments
- adds/changes/deletes.

4.5 Is data collection a use case or a requirement?
4.6 "the data collected needs to be analyzed ..." sounds like a proposed
requirement rather than a use case.
4.7 "capabilities ... should provide ..." sounds like proposed requirements.

--------------- Editorial (by section#)
4: s/Section Section/Section/
	s/decpline/discipline/
4.1.1 s/alowing/allowing/
4.1.2 s/ietf-system ./ietf-system./
4.1.3 s/Hypervisor ./Hypervisor./
4.1.5 s/might also provides/might also provide/
4.2.1 s/represtations/representations/
	s/dsscrete/discrete/

Some of the examples are lacking informative references (radius, YANG
models, MIB modules, SAVI)


David Harrington
[e-mail]
[phone]