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

Hi Michael,

Thanks for that. I will find the time to read your draft carefully
rather than replying in the abstract, but I guess we should not be
too rigid about the format anyway - after all, the goal is not the
format, but to understand and extract the requirements. Indeed, as
you have experienced, each use case raises its own topics.

(I recently reviewed the RTCweb use cases document. Their aproach
is quite relaxed about the description of each use case, but very
systematic in the description of the requirements. See
draft-ietf-rtcweb-use-cases-and-requirements.)

Everybody: we are just starting a discussion with the IETF Area
Directors about a BOF in Toronto based on various AN use cases. More
news later, but now would be a good time to post one or two more use
cases.

Regards
   Brian Carpenter

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.
> 
> 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.
> 
> 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". 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
> 