Re: [nmrg] New Use Case Document: Autonomic Network Bootstrap

Hi everybody,

I find this use case clear and have no objections to
the changes in format compared to the other two. In the end
it's more important (IMHO) to capture the essentials of the use
case than to follow a rigid format, so I think I'd be happy
with use case authors varying the format as long as the main
points are covered. What do other people think?

On 10/05/2014 01:27, Michael Behringer (mbehring) wrote:
> NMRG, 
> 
> As discussed previously, here a use case contribution on Autonomic Networking:
> 
> http://www.ietf.org/internet-drafts/draft-behringer-autonomic-bootstrap-00.txt 
> 
> While writing this document, I realised that we need to adapt the use case template further. At least in my use case, the template didn't flow perfectly yet. Here my main points: 
> 
> 1) We should bring out very explicitly why an autonomic (ie, distributed) solution is preferred or required. In my use case I therefore added a section "Benefits of an Autonomic Solution". As you can see, it's a very short paragraph, but I think we should be explicit about it. After all, this is what our use cases are all about.

Yes, although in a sense the high-level benefit is always the same: get
as close as possible to plug-and-play. So we would need to be stating
something more specific than that.

> 
> 2) The title "Parameters each device can decide for itself" doesn't really gel well in my doc. The issue is the word "decide". My original proposal was "Self-knowledge", which doesn't really capture is fully either. I decided in my version to call this section "Device Based Self-Knowledge and Decisions".  I think that captures both thoughts.

Yes, and of course they are closely related. For example a router could
detect that it has 3 interfaces (self knowledge), one of which has another
router already announcing a prefix (discovery), so it can decide that it
needs to request 2 more prefixes.

> 3) The separation of parameters (old section 4) and Interactions (old section 5) didn't really work out too well either for my use case. In 4 we say "parameters needed" and in 5 "information needed from neighbour devices". 

I see the point, but it is a bit harder in this document to extract
the list of parameters that might be the object of negotiation
with neighbors. I think that will be important when we try to
extract requirements. Very possibly, the description of the
interactions should preceded the identification of the parameters.

   Brian

> In my use case the following slightly re-shuffled structure worked better: 
>    1.  Introduction  
>    2.  Problem Statement 
>    3. Benefits of an Autonomic Solution
>    4.  Intended User and Administrator Experience 
>    5.  Analysis of Parameters and Information Involved
>      5.1.  Device Based Self-Knowledge and Decisions
>      5.2.  Interactions with other devices
>      5.3.  Information needed from Intent 
>      5.4.  Monitoring, diagnostics and reporting
>    6.  Comparison with current solutions
> 
> Thoughts? 
> Michael
> 
> 
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
> 