Subject: [sacm] Appropriate Level for Use Cases

From: Adam Montville <[email-masked]>
Date: Thu, 18 Jul 2013 15:49:14 +0000

Greetings all,

I'd like to start a discussion here on what we, as a community, believe is the appropriate descriptive level for what we are calling a "use case."  >From my background - biased by computer science, electrical and computer engineering, and years of working with software development groups - a "use case" is something that looks a lot like the two I sent earlier this week ([1] and [2]).  

At that level of detail, we have a better understanding of who relying parties are on the capability being described and what pieces of data and/or pre-requisites are otherwise needed for the capability to be successful, which is one of the reasons I like that level of description.  

To me, it makes sense to get what we are calling use cases to an appropriate level of detail to act as representatives of requirements.  Requirements can be derived from the use cases, and from non-use-case sources.  Then, once requirements are better known, we can move on to architectures.

Additionally, David Harrington has asked whether we're paying enough attention to requirements [3], and I agree that we may not be at this time.  But, I would also ask whether we ought to be just yet, at least until a good set of appropriately described use cases exists.  

All that said, I think much of this work can be done in parallel or in quick iterations, but I also think that, if parallel/iterative development of use cases, requirements, and architecture is going to be successful, we need to discuss more here - on the list. :-)

That's my take on it anyway.  I guess the bottom line is that we have an October milestone to have an initial I-D submission to IESG for the architecture, and there are two general steps that  need to complete before we can feel comfortable with the architectural direction - use cases and requirements.

Thoughts?

Adam

[1] http://www.ietf.org/mail-archive/web/sacm/current/msg01282.html 
[2] http://www.ietf.org/mail-archive/web/sacm/current/msg01284.html 
[3] http://www.ietf.org/mail-archive/web/sacm/current/msg01288.html 

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: Rainer Enders <[email-masked]>
Date: Thu, 18 Jul 2013 18:07:17 +0200

Hello Adam,

I agree with your thinking and I found your presentation of use cases
refreshing and promising. With my background as a research engineer it
appears, at least to me, that at times researchers and scientists tend to
overanalyze problems. Having said that I often look at use cases and
wonder if the work that they are intending to support is worth the effort
because they do not offer significant substantiation and differentiation.
We have a large number of standards and if you have a good knowledge base
of such standards you often can imagine simplistic use cases could easily
be addressed by existing standards and wonder what the value add is of the
work that is being proposed. So in that sense use cases are a critical
element. Another related thought I have on this subject is that the lack
of broad industry participation in standardization efforts is a limiting
factor in the sense that there is a difference between practical issues
and theoretical issues. Maybe a way to address this is to take discussions
on standardization efforts into more public forums (trade shows, industry
events)?

Regards,
Rainer

On 7/18/13 8:49 AM, "Adam Montville" <[email-masked]> wrote:

>Greetings all,
>
>I'd like to start a discussion here on what we, as a community, believe
>is the appropriate descriptive level for what we are calling a "use
>case."  From my background - biased by computer science, electrical and
>computer engineering, and years of working with software development
>groups - a "use case" is something that looks a lot like the two I sent
>earlier this week ([1] and [2]).
>
>At that level of detail, we have a better understanding of who relying
>parties are on the capability being described and what pieces of data
>and/or pre-requisites are otherwise needed for the capability to be
>successful, which is one of the reasons I like that level of description.
> 
>
>To me, it makes sense to get what we are calling use cases to an
>appropriate level of detail to act as representatives of requirements.
>Requirements can be derived from the use cases, and from non-use-case
>sources.  Then, once requirements are better known, we can move on to
>architectures.
>
>Additionally, David Harrington has asked whether we're paying enough
>attention to requirements [3], and I agree that we may not be at this
>time.  But, I would also ask whether we ought to be just yet, at least
>until a good set of appropriately described use cases exists.
>
>All that said, I think much of this work can be done in parallel or in
>quick iterations, but I also think that, if parallel/iterative
>development of use cases, requirements, and architecture is going to be
>successful, we need to discuss more here - on the list. :-)
>
>That's my take on it anyway.  I guess the bottom line is that we have an
>October milestone to have an initial I-D submission to IESG for the
>architecture, and there are two general steps that  need to complete
>before we can feel comfortable with the architectural direction - use
>cases and requirements.
>
>Thoughts?
>
>Adam
>
>
>This message and attachments may contain confidential information.  If it
>appears that this message was sent to you by mistake, any retention,
>dissemination, distribution or copying of this message and attachments is
>strictly prohibited.  Please notify the sender immediately and
>permanently delete the message and any attachments.
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Thu, 25 Jul 2013 16:32:43 +0000

Rainer, 

Thanks for your perspective on use cases, it's good to hear.  Sorry for the delay in my response.

With respect to industry participation in standards, there is a reasonably sized group of security software vendors already invested in security automation standards to date.  Moving forward, I agree that getting the word out will continue to be important.  

IMHO, most of us listening to and contributing to this effort should be acting as ambassadors on behalf of the effort.  If you're involved and you see an opportunity to promote the work we're doing - and, most important, get more good people involved - then you ought to be doing that.  I try to do this at every opportunity.  If I'm on a panel, talking to customers, or just talking shop with a peer, I'm evaluating our effort's viability and applicability.  In effect, I evangelize (use of that word probably makes some people cringe) the benefit security automation can bring, and I raise its challenges.

Adam 

> -----Original Message-----
> From: Rainer Enders [mailto:[email-masked]]
> Sent: Thursday, July 18, 2013 9:08 AM
> To: Adam Montville; [email-masked]
> Subject: Re: [sacm] Appropriate Level for Use Cases
> 
> Hello Adam,
> 
> 
> overanalyze problems. Having said that I often look at use cases and wonder
> if the work that they are intending to support is worth the effort because
> they do not offer significant substantiation and differentiation.
> We have a large number of standards and if you have a good knowledge
> base of such standards you often can imagine simplistic use cases could easily
> work that is being proposed. So in that sense use cases are a critical element.
> Another related thought I have on this subject is that the lack of broad
> industry participation in standardization efforts is a limiting factor in the sense
> that there is a difference between practical issues and theoretical issues.
> Maybe a way to address this is to take discussions on standardization efforts
> into more public forums (trade shows, industry events)?
> 
> Regards,
> Rainer
> 
> >That's my take on it anyway.  I guess the bottom line is that we have
> >an October milestone to have an initial I-D submission to IESG for the
> >This message and attachments may contain confidential information.  If
> >it appears that this message was sent to you by mistake, any retention,
> >dissemination, distribution or copying of this message and attachments
> >is strictly prohibited.  Please notify the sender immediately and
> ...

---

From: Rainer Enders <[email-masked]>
Date: Thu, 25 Jul 2013 18:51:52 +0200

Hello Adam,

I will be doing that next week again when delivering a presentation at the
BriForum in Chicago. I see myself very much as an evangelist as well.
Ambassador sounds just too political to me 8)

I don't mean to hijack this forum or enter into a more detailed discussion
about standards participation here. Just to clarify my point of view with
broader participation I meant not just vendors and government which
appears to prevail the scene. There are many other groups and
organizations that could contribute to standardization efforts. But as I
said no need to discuss this further here.

Rainer 

On 7/25/13 9:32 AM, "Adam Montville" <[email-masked]> wrote:

>With respect to industry participation in standards, there is a
>reasonably sized group of security software vendors already invested in
>security automation standards to date.  Moving forward, I agree that
>getting the word out will continue to be important.
>
>IMHO, most of us listening to and contributing to this effort should be
>acting as ambassadors on behalf of the effort.  If you're involved and
>you see an opportunity to promote the work we're doing - and, most
>important, get more good people involved - then you ought to be doing
>that.  I try to do this at every opportunity.  If I'm on a panel, talking
>to customers, or just talking shop with a peer, I'm evaluating our
>effort's viability and applicability.  In effect, I evangelize (use of
>that word probably makes some people cringe) the benefit security
>automation can bring, and I raise its challenges.
>
>Adam 
>
>>wonder
>>element.