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

[Olivier Festor <[e-mail]>]

Dear Michael and NMRG contributors,

comments inline.
Le 9 mai 2014 à 15:27, Michael Behringer (mbehring) <[e-mail]> a écrit :

> NMRG, 
> 
> As discussed previously, here a use case contribution on Autonomic Networking:
> 
> http://www.ietf.org/internet-drafts/draft-behringer-autonomic-bootstrap-00.txt 

(2) Security consideration:
 "An autonomic approach can used to make a bootstrap process secure. » -> "An autonomic approach can BE used to make a bootstrap process secure."


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

An autonomic system is not limited to self-configuration. The other functions should be explicitly mentioned here as well (protecting, healing, …). 


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

Agreed.

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

To bootstrap, a device  needs to set a couple of parameters. 
 -a- some can be found internally (no need to observe anything outside or interact with any 3rd party). The #of interfaces of a router mentioned by Brian in his mail
 -b- some can be « learned » by the device from observation of his environment. No need to interact with a 3rd party
 -c- some can be learned from interacting with the environment (like testing for duplicate addresses for examples)
 -d- some need to be obtained from 3rd party entities (like the cloud service you mention in the autonomic bootstrap.
 -e- and sometimes a few need to be pre-provisionned on the devices

The first 2 (a & b) correspond to your 5.1 subsection. -c- corresponds to 5.2. It is unclear to me if -d- are also to be described in 5.2 or elsewhere ? 
Where in your proposed structure should -e- appear ?

Monitoring, diagnostics and reporting should not be a subsection of the analysis of parameters & information involved but rather a section on its own. 


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

/Olivier Festor

> 
> _______________________________________________
> nmrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nmrg