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

Thanks for your mail, Olivier, responses inline...

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

Thanks, will be fixed.

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

Completely agree, but I don't understand why you mention that. The text you reference doesn't mention configuration at all. Also the draft mentions "config" 4 times, and I believe in the correct context. Please point to some text that you believe needs fixing. 

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

Tx

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

To me, your -d- falls into 5.2., "interaction with other devices". Where the word "devices" doesn't capture the spirit exactly either. 

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

Hmmm... Yes, that would be possible. No strong views here. To me, I saw it as a protocol interaction that has to happen, so it falls into section 5. 

Bottom line: There is no 100% right or wrong. As long as the information is there in the draft, and as long as the main points are covered (ie we haven't missed a main point), I think let's not over engineer this template either. Slight adaptations to specific use cases are legit. 

Michael 

> > 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
> > nmrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/nmrg