Subject: [sacm] Use Case Examination and Potential Requirements

From: Adam Montville <[email-masked]>
Date: Mon, 28 Oct 2013 16:07:07 +0000

All:

I've gone through the use cases and examined them for what I might initially extract as requirements.  In anticipation of some UC removal and addition, I've given each UC a reference ID of the form UC-nn, where n is a digit from 0-9.  Similarly, each requirement is given an ID of the form REQ-nnn, again where n is a digit from 0-9.

I've attached the analysis in csv form to this note.  Should it go up on a wiki instead?

Please note that my analysis is based on a fairly quick pass and makes no attempt to weed out duplicate requirements.  My intent in sharing this is to kindle discussion and gain additional clarity on where we're going with this work.

Regards,

Adam

. . .

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 28 Oct 2013 14:27:28 -0400

Hi Adam,

The venue for official discussion is the mailing list.
I recommend discussing these on the mailing list rather than on a wiki.

I would be careful about using MUST (or any RFC2119 keywords) in your list
of requirements.
We need to turn these into a document that will likely use RFC2119 keywords.

I would recommend using complete sentences rather than just bulleted
requirements.
I would recommend using active voice rather than passive voice.
The IESG often pushes back on passive voice; using active voice makes it
clearer who must do what to be compliant to a standard.
For example, WHO must collect attributes from a given endpoint?

WHO  must make attributes available for evaluation?
Assume we standardize an architecture with endpoints, collectors,
evaluators, data stores, and so on.
Are all of these entities REQUIRED to make attributes available for
evaluation?

You seem to be making security optional, with "MAY support mutual
authentication" etc.
Please look at RFC3365, which specifies an IETF requirement for IETF
standards.
The IESG will consider the RFC3365 requirements when deciding whether to
approve our documents.

If we are going to talk about "policy", we should make sure our terminology
is consistent with previous IETF publications related to policy.
I'd start with RFC4949, since we are a SEC area WG.
We should probably at least look at:
RFC2753 - A Framework for Policy-based Admission Control
RFC2768 - Network Policy and Services: A Report of a Workshop on Middleware
RFC3060 - Policy Core Information Model -- Version 1 Specification
RFC3198 - Terminology for Policy-Based Management
RFC3571 - Framework Policy Information Base for Usage Feedback

Policy-based management, of which at least part of SACM appears to be a
subset, has been discussed in the IETF.
There are a number of IETF standards and documents that resulted from prior
efforts.
A great deal of thought went into the work, and we should not ignore what
has already been done.
RFC3060 has a data model (and an inherent information model) for describing
policies, including policies, groups, rules, properties of rules (enabled,
priority, etc.), conditions, periods, actions, constraints, repository,
associations, aggregations, components, and so on.
They may not apply directly to the work we are doing, but the discussions we
have been having certainly seem to be related to this prior work.
RFC3571 has an information model for monitoring the usage of policies.
This includes allowing one architectural entity (I'll be glad when we reach
consensus on some terms we can use to talk about these things)
To query another architectural entity (such as an evaluator) to determine
which policies (evaluations) are supported, intervals for periodic
reporting, actions, thresholds, etc.

Much of the work on policy was a joint effort with people from DMTF.
The resulting standards have not been widely adopted to my knowledge.
But much of the work probably still deserves study so we don't try to
reinvent the same wheels.

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Montville
> Sent: Monday, October 28, 2013 12:07 PM
> To: [email-masked]
> Subject: [sacm] Use Case Examination and Potential Requirements
> 
> All:
> 
> I've gone through the use cases and examined them for what I might
initially
> extract as requirements.  In anticipation of some UC removal and addition,
> I've given each UC a reference ID of the form UC-nn, where n is a digit
from
> 0-9.  Similarly, each requirement is given an ID of the form REQ-nnn,
again
> where n is a digit from 0-9.
> 
> I've attached the analysis in csv form to this note.  Should it go up on a
wiki
> instead?
> 
> Please note that my analysis is based on a fairly quick pass and makes no
> attempt to weed out duplicate requirements.  My intent in sharing this is
to
> kindle discussion and gain additional clarity on where we're going with
this
> work.

---

From: Adam Montville <[email-masked]>
Date: Mon, 28 Oct 2013 18:51:04 +0000

> From: ietfdbh [mailto:[email-masked]]
> Sent: Monday, October 28, 2013 1:27 PM
> To: Adam Montville; [email-masked]
> Subject: RE: [sacm] Use Case Examination and Potential Requirements
> 
> Hi Adam,
> 

My suggestion was where to put the csv file and not about where to conduct a discussion.

> We need to turn these into a document that will likely use RFC2119

All of the WG documents will use appropriate language.  You'll note that I did not claim to be compliant with RFC2119 in the requirements I (very quickly) extracted from the use cases.

> I would recommend using complete sentences rather than just bulleted

Did I mention I did this quickly? ;-)  And, this work is not intended to be anything other than a discussion piece to assist the WG in extracting requirements from the Use Cases.

> Are all of these entities REQUIRED to make attributes available for

Further refinement of terse, high-level requirements is needed to answer these questions, and yours are exemplary of the very questions I hope the WG can start discussing.

> You seem to be making security optional, with "MAY support mutual

Optional security wasn't my intent.  Instead, I was (perhaps going against my own rule-of-thumb) assuming that we'd not necessarily be concerned with authentication - that's been done before so our system can probably leverage something that already exists.

> If we are going to talk about "policy", we should make sure our terminology is
> consistent with previous IETF publications related to policy.

I agree that the WG should use terminology in a consistent manner.  This does not, however, omit the possibility that our use of the term "policy" may be different from any other IETF-related use.  During one of our BoF sessions I presented an overview of our problem domain, which provided context for the level of policy we're talking about.  

> There are a number of IETF standards and documents that resulted from
> prior efforts.

At this point, having not investigated all of the RFCs you've mentioned here, I believe we are talking about policy at one or two levels above that addressed by RFC3060.

> consensus on some terms we can use to talk about these things) To query
> another architectural entity (such as an evaluator) to determine which
> policies (evaluations) are supported, intervals for periodic reporting, actions,
> thresholds, etc.
> 

Agree.

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Adam Montville
> > extract as requirements.  In anticipation of some UC removal and
> > addition, I've given each UC a reference ID of the form UC-nn, where n
> > is a digit
> from
> > Please note that my analysis is based on a fairly quick pass and makes
> > no attempt to weed out duplicate requirements.  My intent in sharing
> > this is
> to
> ...

. . .