Re: [nmrg] Autonomic Use Cases

["Michael Behringer (mbehring)" <[e-mail]>]

Thanks Brian. 

Let's have a quick look, and make sure we're in sync. We agreed to have a common format for the use cases. 

I had proposed the following outline: 
	Title
	Problem Statement
	Intended user / administrator experience
	Intent
	Local knowledge
	Communication requirements

You have used the following in your draft: 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Intended User and Administrator Experience  . . . . . . . . .   3
   4.  Analysis of Parameters and Information Involved . . . . . . .   3
     4.1.  Parameters each device can decide for itself  . . . . . .   4
     4.2.  Information needed from policy intent . . . . . . . . . .   4
   5.  Interaction with other devices  . . . . . . . . . . . . . . .   4
     5.1.  Information needed from neighbor devices  . . . . . . . .   5
     5.2.  Monitoring, diagnostics and reporting . . . . . . . . . .   6
   6.  Comparison with current solutions . . . . . . . . . . . . . .   6

Let's not haggle over details, but learn as we move along. We can change my proposal to your layout. Only, 5.1 should read "...from other devices" - interactions are not limited to neighbors. 

I've taken the liberty to use your XML file Brian as a basis for a generic template. 

Anyone writing a use case: The attached XML file produces exactly the required outline. Just fill in your details. So, let's get going! (I've started to write "my" use case. Others?)

Michael

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: 10 April 2014 10:11
> To: Michael Behringer (mbehring)
> Cc: [e-mail]
> Subject: Re: [nmrg] Autonomic Use Cases
> 
> Michael and everybody,
> 
> I apologise for being silent for a month on the list, but various things
> intervened.
> 
> Shortly, I'll be posting a first draft of a use case. First though, here are a few
> comments on what Michael proposed for use cases. I have trimmed the text
> of the proposal:
> 
> > Problem Statement:
> 
> Yes, we certainly need this.
> 
> > Intended user / administrator experience:
> 
> Yes
> 
> > Intent: Strictly speaking intent is part of the administrator
> > experience, but should probably explained explicitly with a high-level
> > view
> 
> Yes, but I'm not so sure it's part of the user experience. At least for my use
> case, as you'll see, it's probably a vendor default.
> 
> > Local knowledge: What the function needs to know about the capabilities
> of the node itself, and which local resources need to be accessed.
> 
> I found this a bit abstract. Concretely, it's a matter of which parameters each
> device can decide for itself, without external information. Logically,
> therefore, it comes before intent (as far as the device is concerned).
> 
> > Communication requirements: The requirements for message exchange,
> discovery, negotiation, etc with other autonomic nodes.
> 
> Firstly, the communication might be with non-autonomic nodes too!
> Secondly, I found this a bit closer to the solution than the problem. So in my
> version, this topic is about the information needed from neighbor devices,
> not about messages.
> 
> Also, I found that I needed to say something about monitoring (which
> affects each device, so can't just be described as part of the user
> experience, although it affects that too).
> 
> Finally, it seems useful to compare the AN use case with current solutions.
> If we can't describe benefits, we are a bit stuck.
> 
> > Use cases are not required to outline a solution in detail
> 
> Understood. But it's a matter of taste and judgment where the problem
> statement stops and hints of the solution begin...
> 
> Anyway - the best test for all this is an example use case, which will come
> very soon.
> 
>    Brian
> 
> 
> 
> 
> On 08/03/2014 12:47, Michael Behringer (mbehring) wrote:
> > NMRG,
> >
> > During the meeting we mentioned the need to document use cases. This
> section in the definitions draft is so far empty. Since we should have that
> section BEFORE working out the use cases, I drafted something up here.
> >
> > I also realised that while we haven't really written down in the draft that
> the key point of this work really is to work out common infrastructure
> requirements. So I'm also suggesting an additional short section in the
> Design Goals section:
> >
> >       <section title="Common Autonomic Networking Infrastructure">
> > 	<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that
> there are already a number of fully or partially autonomic functions
> available today. However, they are largely independent, and each has its
> own methods and protocols to communicate, discover, define and
> distribute policy, etc. </t>
> > 	<t>The goal of the work on autonomic networking in the IETF is
> therefore not just to create autonomic functions, but to define a common
> infrastructure that autonomic functions can use. This autonomic networking
> infrastructure may contain common control and management functions such
> as messaging, service discovery, negotiation, intent distribution, etc. A
> common approach to define and manage intent is also required. </t>
> > 	<t>Refer to the reference model below: All the components around
> the "autonomic service agents" should be common components, such that
> the autonomic service agents do not have to replicate common tasks
> individually. </t>
> >       </section>
> >
> > Comments? Does this capture the idea well?
> >
> > And then, the use case section could look like this:
> >
> >       <section title="Guidelines for Case Studies">
> > 	<t>Case studies and problem statements are mandatory to
> understand common requirements for autonomic functions. This section
> explains how case studies should be outlined and what they should
> describe:
> >         <list style="symbols">
> > 	  <t>Title</t>
> > 	  <t>Problem Statement: An explanation which problem is being
> addressed, with information about existing solutions and their
> shortcomings.</t>
> > 	  <t>Intended user / administrator experience: The goal of
> autonomic networking is to simplify network administration and usage. Use
> cases should point out how their experience differs from current solutions.
> If a use case depends on configuration, it may include configuration
> samples, although obviously the goal is to reduce or eliminate
> configuration. </t>
> > 	  <t>Intent: Strictly speaking intent is part of the administrator
> experience, but should probably explained explicitly with a high-level view
> on how the autonomic function could be defined in intent (if required). </t>
> > 	  <t>Local knowledge: What the function needs to know about the
> capabilities of the node itself, and which local resources need to be
> accessed.</t>
> > 	  <t>Communication requirements: The requirements for message
> exchange, discovery, negotiation, etc with other autonomic nodes. </t>
> >         </list>
> > 	</t>
> > 	<t>Use cases are not required to outline a solution in detail, nor to
> specify precise protocol or intent details. They are used at this point to
> determine a consolidated approach to developping an autonomic
> networking infrastructure. </t>
> >       </section>
> >
> > Comments?
> > Michael
> >
> > _______________________________________________
> > nmrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/nmrg
> >