Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Mar 2015 16:40:51 +1300

Hi John and everybody,

Replying to some comments received privately, on the list with permission:
On 09/03/2015 22:55, Sheng Jiang wrote:
> Hi, authors of draft-carpenter-anima-gdn-protocol
> 
> The below are some comments from my colleague, Dr. John Strassner. Although I personally think your protocol designs have the ability to meet his requirements for knowledge exchanging among autonomic nodes, it is better you could discuss directly and maybe include some modification/clarification in the future version. I also encourage you to discuss this in ANIMA mail list openly.
> 
> Best regards,
> 
> Sheng
> 
>> -----Original Message-----
>> From: John Strassner
>> Sent: Friday, March 06, 2015 6:43 AM
>> To: Sheng Jiang; John Strassner
>>
>> Dear Sheng,
>>
>> I read the charter and am starting on the drafts.
>>
>>>> autonomics require the ability to share and
>>>> exchange knowledge in an interoperable fashion. I fail to see how this is
>>>> even discussed in ANIMA.
>>>
>>> BTW, the ability to share and exchange knowledge in an interoperable fashion
>>> looks like GNDP (Generic Discovery and Negotiation Protocol) in ANIMA. This
>>> protocol is designed to support information discovery and bi-direction
>>> negotiation.
>>
>> It appears that GDNP covers some, but not all, of what I am talking about.

Indeed, it isn't claiming to cover everything. The idea is that
draft-behringer-anima-reference-model will evolve to show how things
fit together, which will help us to identify holes.

>> However, the following statement from the GDNP draft is misleading, if not
>> just plain wrong:
>>
>> "In order to fulfil autonomy, devices that embody autonomic service
>> agents need to be able to discover each other, to synchronize state
>> with each other, and to negotiate parameters and resources directly
>> with each other."
>>
>> First, autonomic networks are not necessarily autonomous. Autonomy, in its
>> most generic form, is the ability to have the power for an entity to govern
>> itself. If every network element governs itself without regard to other, higher
>> level principles, you don't even have a network. :-)

Sure. That is the role for what we call "intent" which is defined
in draft-irtf-nmrg-autonomic-network-definitions but is not yet
in Anima scope.

>> Second, the three concepts mentioned in the above excerpt (discoverability,
>> synchronization of state, and parameter negotiation) are necessary but
>> clearly not sufficient to have autonomic operation. I was talking about the
>> ability to exchange knowledge (e.g., all or part of an information model)
>> between entities. It doesn't appear that this is covered in ANIMA yet, though I
>> haven't read all of the materials.

My personal view is that this is going to be resolved topic by topic.
In GDNP-speak that means that it will be resolved by individual Objective
definitions, and GDNP will just act as a neutral carrier. (You can quite
fairly argue that this means we are ducking the problem for now.)
Another way to say this is that each type of autonomous service agent will
solve this problem for its own target parameters.

Now, again IMHO, this is why we state in GDNP that the format of the
value of an objective "...might be inherited from an
existing management or configuration protocol, the objective option
acting as a carrier for that format.  The data structure might be
defined in a formal language, but that is a matter for the
specifications of individual objectives.  There are many candidates,
according to the context, such as ABNF, RBNF, XML Schema, possibly
YANG, etc.  The GDNP protocol itself is agnostic on these questions."

My expectation is that some objectives will need a formal information
model and that others won't, and that there's no reason we couldn't
inherit existing IMs when they are relevant. But that whole question
is also out of charter scope for now. As you know better than most
people, John, defining an IM can become a very laborious business and
for now we want to get started on simple cases that don't need it.

>> If you cannot exchange knowledge, you will
>> never be autonomic in the computer science sense. 

You will find very similar words in draft-irtf-nmrg-an-gap-analysis.

<snip>

Regards
    Brian

>> regards,
>> John
>>
>> Dr. John Strassner, Ph.D.
>> CTO, Software Laboratory, CRD
>>
>>
>> Futurewei Technologies
>> US R&D Center
>> 2330 Central Expressway
>> Building A, office A2-2143
>> Santa Clara, California   95050
>>  Office:  +1.408.330.4923
>>  Email:   [email-masked]
>>
>>
>> Best regards,
>>
>> Sheng

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 11 Mar 2015 10:42:40 +0000

John, 

Adding to Brian/Sheng my view, there are two important points to note: 

1) What you see now is just the start. In this first phase we're not actually standardising any autonomic service agents (as we call them), but we're preparing an infrastructure for such agents. Meaning, such agents can count on all the "mechanics" to talk to other agents: Addressing, routing, security, simple discovery, negotiation, etc. We call this the autonomic networking infrastructure, and our goal is to make this infrastructure "self-managing" itself, specifically, it should self-configure. 

This infrastructure is not complete, as you correctly point out. But all of the functions you mention (e.g., knowledge exchange) first of all require a solid communications infrastructure. 

In the WG charter you see the elements of the infrastructure, and a couple of use cases for autonomic service agents. In this first phase the intention is to validate the autonomic networking infrastructure with those use cases. See also the UCAN BoF notes, where more use cases were discussed. Again, we're looking at simple use cases to start with, and work bottom-up. 

2) We are not trying to define fully autonomic nodes, but autonomic functions. In other words, we expect nodes to be partially managed in the traditional way, and some functions to be autonomic. In the future there may be cases of fully autonomic nodes. 

As we take on new use cases, we define their requirements, and address the delta in the autonomic networking infrastructure, bottom up. With the reference model we need to make sure that we're not going down a track that will make future use cases impossible or hard to support. This is of course the main challenge. Your input would be very valuable in this process. 

What are your thoughts? 

Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 10 March 2015 04:41
> To: John Strassner
> Cc: Liubing (Leo); Anima WG; [email-masked]
> Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-
> protocol
> 
> Hi John and everybody,
> 
> > The below are some comments from my colleague, Dr. John Strassner.
> Although I personally think your protocol designs have the ability to meet
> his requirements for knowledge exchanging among autonomic nodes, it is
> better you could discuss directly and maybe include some
> modification/clarification in the future version. I also encourage you to
> discuss this in ANIMA mail list openly.
> >
> > Best regards,
> >
> > Sheng
> >
> >>>> autonomics require the ability to share and exchange knowledge in
> >>>> an interoperable fashion. I fail to see how this is even discussed
> >>>> in ANIMA.
> >>>
> >>> BTW, the ability to share and exchange knowledge in an interoperable
> >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol)
> >>> in ANIMA. This protocol is designed to support information discovery
> >>> and bi-direction negotiation.
> >>
> Indeed, it isn't claiming to cover everything. The idea is that draft-
> behringer-anima-reference-model will evolve to show how things fit
> together, which will help us to identify holes.
> 
> >> However, the following statement from the GDNP draft is misleading,
> >> if not just plain wrong:
> >>
> >> First, autonomic networks are not necessarily autonomous. Autonomy,
> >> in its most generic form, is the ability to have the power for an
> >> entity to govern itself. If every network element governs itself
> >> without regard to other, higher level principles, you don't even have
> >> a network. :-)
> 
> Sure. That is the role for what we call "intent" which is defined in draft-irtf-
> nmrg-autonomic-network-definitions but is not yet in Anima scope.
> 
> >> Second, the three concepts mentioned in the above excerpt
> >> (discoverability, synchronization of state, and parameter
> >> negotiation) are necessary but clearly not sufficient to have
> >> autonomic operation. I was talking about the ability to exchange
> >> knowledge (e.g., all or part of an information model) between
> >> entities. It doesn't appear that this is covered in ANIMA yet, though I
> definitions, and GDNP will just act as a neutral carrier. (You can quite fairly
> argue that this means we are ducking the problem for now.) Another way to
> say this is that each type of autonomous service agent will solve this
> problem for its own target parameters.
> 
> Now, again IMHO, this is why we state in GDNP that the format of the value
> of an objective "...might be inherited from an existing management or
> configuration protocol, the objective option acting as a carrier for that
> format.  The data structure might be defined in a formal language, but that
> is a matter for the specifications of individual objectives.  There are many
> candidates, according to the context, such as ABNF, RBNF, XML Schema,
> possibly YANG, etc.  The GDNP protocol itself is agnostic on these
> questions."
> 
> model and that others won't, and that there's no reason we couldn't inherit
> existing IMs when they are relevant. But that whole question is also out of
> charter scope for now. As you know better than most people, John, defining
> an IM can become a very laborious business and for now we want to get
> started on simple cases that don't need it.
> 
> >> If you cannot exchange knowledge, you will never be autonomic in the
> >> computer science sense.
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: John Strassner <[email-masked]>
Date: Wed, 11 Mar 2015 17:34:21 -0700

Hi Brian,

thanks for your quick reply. I'm out of the country, so sorry for the
delay. Please see inline, look for <jcs>..</jcs>.

...elided...

>>>> exchange knowledge in an interoperable fashion. I fail to see how this
is

<jcs>
This is probably my error, sorry.
I've done a lot of research in autonomics, and even built a couple of
things. :-)
What I meant in the snipped above is the ability to pass enough information
to other participating nodes so that the nodes can understand the current
context, make context-relevant decisions, and then take appropriate actions.
For example, if I was using ontologies to specify semantics, I would likely
use something like CL (Common Logic).
As another example, autonomic systems **learn** from the environment.
Hence, their repositories grow, information is validated and invalidated,
etc.
Hopefully that makes more sense...
</jcs>

>>> BTW, the ability to share and exchange knowledge in an interoperable
fashion

<jcs>
I promise to read this next. :-)
My quick comment is that in systems I have built, it is important to pass
parts of the model among cooperating autonomic nodes. I don't detect this
ability in GDNP.

Another important requirement was for "more powerful" processing nodes to
help "less powerful" processing nodes. This was typically implemented by
advertising capabilities as well as requests for help. I think that GDNP
could evolve to serve these and similar needs.
</jcs>

<jcs>
Another item for my reading list.
Looking at page 4, it **seems** that you are defining an autonomic system
as a system driven by policy. I like that :-)
However, this is a difficult goal. I think that it is unlikely that a
**single** level of intent can ever be built. Rather, much like the policy
continuum that I defined, I think that there is a continuum of intents,
where each intent is expressed using a policy that may use different
concepts and terminology. We do that today, when a business person decrees
that this Customer gets Gold Service, and a network admin translates that
to CLI.
Thoughts?
</jcs>

>> Second, the three concepts mentioned in the above excerpt
(discoverability,

<jcs>
Actually, this isn't a bad approach. My main issue is that knowledge
exchange is far broader than discovery and parameter-specific data.
</jcs>

<jcs>
Yes, I seem to have continually skewered myself on information models. :-)
While I very much agree with your approach, I would note that you should
either say IM **fragments** or limit this to one IM.
</jcs>

You will find very similar words in draft-irtf-nmrg-an-gap-analysis.
<jcs>
Yikers, another draft. Is there a list of all drafts that may be eventually
considered?
</jcs>

< snip>

Regards
    Brian

On Mon, Mar 9, 2015 at 8:40 PM, Brian E Carpenter <
[email-masked]> wrote:

> fashion
> (discoverability,

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 11 Mar 2015 18:22:32 -0700

Hallo Michael,
it's been a long time. :-)

I understand, and agree, with your first point.

Regarding the second point, I understand your point about fully autonomic
nodes. In addition, I think the WG should be commended for worrying about
legacy elements and processes from the outset.

First question: could I characterize your approach as having three types of
nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An
autonomically-aware node is one that fully autonomic nodes can communicate
with, and which understands (perhaps after translation) what functions are
required of it and what functions it can offer. An autonomically-unaware
node is a dumb rock (e.g., a hub).

Then, I could say that an autonomic function is either be supported
directly by a fully autonomic node, or built from a set of nodes (some of
which are not capable of performing autonomic functions).

Second question: performing an autonomic function is a set of behaviors.
What's important is the end result, not the individual behaviors. So, as
long as each individual behavior can be rigorously defined (e.g., using a
software contract, where the behavior satisfies a set of pre- and
post-conditions as well as a set of invariants), then (in theory) they
should be able to be composited together.

Thoughts?

best regards,
John

On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> 1) What you see now is just the start. In this first phase we're not
> actually standardising any autonomic service agents (as we call them), but
> we're preparing an infrastructure for such agents. Meaning, such agents can
> count on all the "mechanics" to talk to other agents: Addressing, routing,
> security, simple discovery, negotiation, etc. We call this the autonomic
> networking infrastructure, and our goal is to make this infrastructure
> "self-managing" itself, specifically, it should self-configure.
>
> This infrastructure is not complete, as you correctly point out. But all
> of the functions you mention (e.g., knowledge exchange) first of all
> require a solid communications infrastructure.
>
> In the WG charter you see the elements of the infrastructure, and a couple
> of use cases for autonomic service agents. In this first phase the
> intention is to validate the autonomic networking infrastructure with those
> use cases. See also the UCAN BoF notes, where more use cases were
> discussed. Again, we're looking at simple use cases to start with, and work
> bottom-up.
>
> 2) We are not trying to define fully autonomic nodes, but autonomic
> functions. In other words, we expect nodes to be partially managed in the
> traditional way, and some functions to be autonomic. In the future there
> may be cases of fully autonomic nodes.
>
> As we take on new use cases, we define their requirements, and address the
> delta in the autonomic networking infrastructure, bottom up. With the
> reference model we need to make sure that we're not going down a track that
> will make future use cases impossible or hard to support. This is of course
> the main challenge. Your input would be very valuable in this process.
>
> What are your thoughts?
>
> Michael
>
>
> fairly
> value
> inherit

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2015 14:38:29 +1300

On 12/03/2015 13:34, John Strassner wrote:
...
> Yikers, another draft. Is there a list of all drafts that may be eventually

The official list of related drafts for the WG is at
http://datatracker.ietf.org/wg/anima/documents/

Then there were two drafts developed in the Network Management Research
Group, which are in the final stages of review to become RFCs:

http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis
http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions

I think that's it for *directly* relevant drafts, but there are
at least two others relevant to security bootstrapping:

draft-ietf-netconf-zerotouch
draft-he-6lo-analysis-iot-sbootstrapping

and we had a bunch of possible use cases at the UCAN BOF
https://tools.ietf.org/wg/anima/trac/wiki/UCAN

    Brian

---

From: John Strassner <[email-masked]>
Date: Wed, 11 Mar 2015 19:42:13 -0700

Thanks Brian!

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 12 Mar 2015 08:17:04 +0000

Inline….

From: John Strassner [mailto:[email-masked]]
Sent: 12 March 2015 02:23
To: Michael Behringer (mbehring); John Strassner
Cc: Brian E Carpenter; John Strassner; Liubing (Leo); Anima WG
Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol

Hallo Michael,

MB: Indeed – the world is small! ☺

Regarding the second point, I understand your point about fully autonomic nodes. In addition, I think the WG should be commended for worrying about legacy elements and processes from the outset.

First question: could I characterize your approach as having three types of nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An autonomically-aware node is one that fully autonomic nodes can communicate with, and which understands (perhaps after translation) what functions are required of it and what functions it can offer. An autonomically-unaware node is a dumb rock (e.g., a hub).

MB: Yes, we’re essentially thinking along the same lines, but phrase it differently. We agree on “fully autonomic”, that’s the easy one.
Now, your “autonomically-aware” definition translates in our world to “supports the Autonomic Networking Infrastructure”, which is exactly what we’re defining right now in ANIMA. I think this definition has two sub-flavours:

a)      the node supports the AN Infrastructure  and one or several autonomic service agents (but is not fully autonomic)

b)      the node supports the AN Infrastructure, but may not be aware of autonomic service agents that run on other nodes.
Point a) is a subset of b). Example: topology is A----B----C. All nodes support the AN infrastructure. A and C should be able to negotiate parameters for an autonomic service agents, even if B doesn’t implement that function.
I think it’s pretty obvious. I just want to point out that in our thinking there is infrastructure and autonomic service agents. An “autonomically aware” node MUST have the AN infrastructure, and MAY have autonomic service agents.

BTW, an “autonomically unaware” node is not just a dumb rock like a hub. Also traditional devices (e.g. routers) which do not support the AN infrastructure fall into that category.

Then, I could say that an autonomic function is either be supported directly by a fully autonomic node, or built from a set of nodes (some of which are not capable of performing autonomic functions).

MB: I think when you say “autonomic function” you mean a function across various nodes, right? In our wording, a node runs an autonomic service agent. A group of such nodes implement an autonomic function.

Second question: performing an autonomic function is a set of behaviors. What's important is the end result, not the individual behaviors. So, as long as each individual behavior can be rigorously defined (e.g., using a software contract, where the behavior satisfies a set of pre- and post-conditions as well as a set of invariants), then (in theory) they should be able to be composited together.

What’s the question? ;-)   Yes, I agree. The Autonomic Control Plane is an example of this. Each nodes carries out a few local actions (authenticating neighbors, building tunnels to them, etc), and the net result is a self-managing overlay network with some nice properties.

Thanks for your input and validation of our work!
Michael

Thoughts?

best regards,
John

On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:
John,

What are your thoughts?

Michael

> From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E
> Carpenter
> Cc: Liubing (Leo); Anima WG; [email-masked]<mailto:[email-masked]>
> >>  Email:   [email-masked]<mailto:[email-masked]>
> >>
> >>
> >> Best regards,
> >>
> >> Sheng
>
> [email-masked]<mailto:[email-masked]>

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 12 Mar 2015 04:22:03 -0700

Hallo Michael,

inline as well...look for <jcs>..</jcs>

Hallo Michael,

MB: Indeed – the world is small! J

MB: Yes, we’re essentially thinking along the same lines, but phrase it
differently. We agree on “fully autonomic”, that’s the easy one.

Now, your “autonomically-aware” definition translates in our world to
“supports the Autonomic Networking Infrastructure”, which is exactly what
we’re defining right now in ANIMA. I think this definition has two
sub-flavours:

a)      the node supports the AN Infrastructure  and one or several
autonomic service agents (but is not fully autonomic)

b)      the node supports the AN Infrastructure, but may not be aware of
autonomic service agents that run on other nodes.

<jcs>

I'm with you so far...

</jcs>

Point a) is a subset of b). Example: topology is A----B----C. All nodes
support the AN infrastructure. A and C should be able to negotiate
parameters for an autonomic service agents, even if B doesn’t implement
that function.

<jcs>

By subset, do you subclass?

If "C" is a fully autonomic node, then I'm happy and understand. If not,
then I'm confused.

</jcs>

I think it’s pretty obvious. I just want to point out that in our thinking
there is infrastructure and autonomic service agents. An “autonomically
aware” node MUST have the AN infrastructure, and MAY have autonomic service
agents.

<jcs>

This makes perfect sense.

Agents are obvious - enough so that I forgot to mention them :-)

However, since you bring them up, are you assuming full FIPA compliant
agents, or something else? Not having decided yet is fine too.

</jcs>

BTW, an “autonomically unaware” node is not just a dumb rock like a hub.
Also traditional devices (e.g. routers) which do not support the AN
infrastructure fall into that category.

<jcs>

Agreed. I was giving the traditional router the benefit of the doubt :-)
but for this purpose, yes, it is a dumb rock.

</jcs>

MB: I think when you say “autonomic function” you mean a function across
various nodes, right? In our wording, a node runs an autonomic service
agent. A group of such nodes implement an autonomic function.

<jcs>

Yes, agreed

</jcs>

What’s the question? ;-)   Yes, I agree. The Autonomic Control Plane is an
example of this. Each nodes carries out a few local actions (authenticating
neighbors, building tunnels to them, etc), and the net result is a
self-managing overlay network with some nice properties.

<jcs>

Oops, sorry. My caffeine/blood ratio must have been too low. :-)

My question was how the behaviors are composited. When I built similar
functionality, I used software contracts to manage the functions performed
by the agents. At the time, I didn't see many other examples of this, so I
was curious if ANIMA had thought about how to standardize the agent
behavior? With software contracts, this becomes easier, as the function is
characterized by the contract. Make sense?

</jcs>

Michael

<jcs>

I now understand a lot more, thanks to you, Brian, and Sheng for your
answers and patience. I think the work is promising, and would like to
participate.

</jcs>

Thoughts?

best regards,

John

mfg,
John

On Thu, Mar 12, 2015 at 1:17 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

>  Inline….
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* 12 March 2015 02:23
> *To:* Michael Behringer (mbehring); John Strassner
> *Cc:* Brian E Carpenter; John Strassner; Liubing (Leo); Anima WG
> *Subject:* Re: [Anima] Some comments for
> draft-carpenter-anima-gdn-protocol
>
>
>
> Hallo Michael,
>
> MB: Indeed – the world is small! J
>
>
>
> First question: could I characterize your approach as having three types
> of nodes: fully autonomic, autonomically-aware, and
> autonomically-unaware? An autonomically-aware node is one that fully
> autonomic nodes can communicate with, and which understands (perhaps after
> translation) what functions are required of it and what functions it can
> offer. An autonomically-unaware node is a dumb rock (e.g., a hub).
>
>
>
> MB: Yes, we’re essentially thinking along the same lines, but phrase it
> differently. We agree on “fully autonomic”, that’s the easy one.
>
> Now, your “autonomically-aware” definition translates in our world to
> “supports the Autonomic Networking Infrastructure”, which is exactly what
> we’re defining right now in ANIMA. I think this definition has two
> sub-flavours:
>
> a)      the node supports the AN Infrastructure  and one or several
> autonomic service agents (but is not fully autonomic)
>
> b)      the node supports the AN Infrastructure, but may not be aware of
> autonomic service agents that run on other nodes.
>
> Point a) is a subset of b). Example: topology is A----B----C. All nodes
> support the AN infrastructure. A and C should be able to negotiate
> parameters for an autonomic service agents, even if B doesn’t implement
> that function.
>
> I think it’s pretty obvious. I just want to point out that in our thinking
> there is infrastructure and autonomic service agents. An “autonomically
> aware” node MUST have the AN infrastructure, and MAY have autonomic service
> agents.
>
>
>
> BTW, an “autonomically unaware” node is not just a dumb rock like a hub.
> Also traditional devices (e.g. routers) which do not support the AN
> infrastructure fall into that category.
>
>
>
> MB: I think when you say “autonomic function” you mean a function across
> various nodes, right? In our wording, a node runs an autonomic service
> agent. A group of such nodes implement an autonomic function.
>
>
>
> What’s the question? ;-)   Yes, I agree. The Autonomic Control Plane is an
> example of this. Each nodes carries out a few local actions (authenticating
> neighbors, building tunnels to them, etc), and the net result is a
> self-managing overlay network with some nice properties.
>
>
>

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 12 Mar 2015 12:18:16 +0000

[...]
 
<jcs>
By subset, do you subclass?
If "C" is a fully autonomic node, then I'm happy and understand. If not, then I'm confused.
</jcs>

MB: I'm not really considering fully autonomic nodes for now. We won't hit that target for a long time, so I always assume partially autonomic, ie, certain functions are autonomic, others not. But I think (!) it's just a question of wording, and we're actually in sync. Say, for the sake of the discussion that A and C implement an autonomic routing function, which is not configured traditionally any more. All parameters are negotiated, and policy is set through intent not configuration. So this is a fully autonomic function. The fact that say QoS is still configured manually to me is not really relevant here. Thoughts? 

<jcs>
This makes perfect sense.
Agents are obvious - enough so that I forgot to mention them :-)
However, since you bring them up, are you assuming full FIPA compliant agents, or something else? Not having decided yet is fine too.
</jcs>

MB: Not decided yet. 

<jcs>
Agreed. I was giving the traditional router the benefit of the doubt :-) but for this purpose, yes, it is a dumb rock.
</jcs>

<jcs>
Yes, agreed
</jcs>

<jcs>
Oops, sorry. My caffeine/blood ratio must have been too low. :-)
My question was how the behaviors are composited. When I built similar functionality, I used software contracts to manage the functions performed by the agents. At the time, I didn't see many other examples of this, so I was curious if ANIMA had thought about how to standardize the agent behavior? With software contracts, this becomes easier, as the function is characterized by the contract. Make sense?
</jcs>

MB: We aren't really that far yet in ANIMA, but should clearly explore this way. 

<jcs>
I now understand a lot more, thanks to you, Brian, and Sheng for your answers and patience. I think the work is promising, and would like to participate.
</jcs>

MB: That would be cool. Will you be in Dallas? 

Michael

---

From: John Strassner <[email-masked]>
Date: Thu, 12 Mar 2015 15:33:38 -0700

Hallo Michael,...
replies inline, look for <jcs2>..</jcs2>

best regards,
John

On Thu, Mar 12, 2015 at 5:18 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> MB: I'm not really considering fully autonomic nodes for now. We won't hit
> that target for a long time, so I always assume partially autonomic, ie,
> certain functions are autonomic, others not. But I think (!) it's just a
> question of wording, and we're actually in sync. Say, for the sake of the
> discussion that A and C implement an autonomic routing function, which is
> not configured traditionally any more. All parameters are negotiated, and
> policy is set through intent not configuration. So this is a fully
> autonomic function. The fact that say QoS is still configured manually to
> me is not really relevant here. Thoughts?
>

<jcs>
I completely agree. I've always felt that the purpose of autonomic
functions is to augment and simplify, not to rip and replace. So in your
example, the fact that part of the behavior is now easier to configure and
manage is great! We don't need to solve everything at once.
</jcs>

<jcs>
No worries. I know FIPA well, and can help translate it. :-) That being
said, I have no strong opinions about whether we should make it compliant
or not.
</jcs>

<jcs>
Yes, I will be there for both sessions.
</jcs>

-- 
regards,
John