Subject: [Anima] Next steps for the reference document

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Jun 2015 13:18:44 +0000

Thanks for all who volunteered to participate in the reference doc. While detailed discussions may be between the contributors, the main technical discussions should probably take place on the main list. Here, I summarise my view on what needs to be done in the reference document. 

If someone thinks he/she can produce text for the respective sections, please let me / the list know. 

The overall goal is to show how all the various drafts, protocols, and discussions in the ANIMA WG fit together.

Points to address: 

-	We should have a short section on intent. Explaining ingest of intent, distribution, the nature (on top of what's in RFC7575). That intent is signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent distribution is handled in section 7.3)
-	Do we want to address "constrained" AN nodes, with limited capabilities, here? I think so... We'll need that for AN in constrained environments. This could go into a new section in section 3: "constrained network elements". 
-	The masa section needs to be written. The masa will be an optional element. Needs to point to the bootstrap draft, which explains the basics. 
-	Naming section needs meat. What names are used for, where it is in the domain cert. 
-	Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node). 
-	Domain certificate template. We should write a section on the AN domain certificate. How the various fields are used. 
-	Need to explain sub-domains
-	Section 9 needs to be worked out. This is all about conflict resolution. Maybe we should re-name that section? RFC 7575 already mentions this. Maybe we don't need much more here. 
-	trust management: inside a domain, between domain and sub-domain, and between domains. This should become a new section. 
-	Need to treat the question of the "out of band" ACP versus the inline ACP. The two models both work, but there are implications, different benefits, drawbacks, etc. This needs to be explained. 
-	Routing: In the case of a virtually separate ACP, as in draft-behringer-anima-autonomic-control-plane, we need to also define a routing protocol (thinking of the discussion in homenet, this might be "fun"...) 
-	Need considerations for APIs: How can ASAs use the ANI? 
-	Need considerations for a data model. What it should cover, scope. 
-	We should also describe the management angle
-	Security considerations need to be expanded. Threat analysis needs work; need general security considerations, talk about the PKI and trust model, etc. 

Thoughts? Anything missing? Any volunteer for a specific part? 

Michael

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 4 Jun 2015 16:55:44 +0200

Hi Michael,

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / 
conflict resolution" (as per draft-behringer-anima-reference-model-01), 
and section 9 - "Hybrid Approach with Non-Autonomic Functions".

For "constrained" AN nodes, I think they are in scope, but what is the 
implication for the reference model document? Do we already have some 
inputs/requirements (e.g. from other WGs or sources) that could 
enlighten how / to which extent autonomic networks / their 
functionalities and mechanisms shall (or not) adapt (to such constrained 
nodes)?

I am not quite sure what you meant by the "management angle"... I assume 
you are talking about the management/operations of the whole system (as 
if deployed by e.g. a network operator). if correct, then I think some 
aspects of lifecycle / phases/ operations should be considered / written 
in the document. I can contribute to this but would prefer to start with 
some group discussions to see if we agree on the scope first.

A tricky (missing) part might be the relationships among the various 
component. If judged useful (I think it is especially for ANIMA 
"outsiders"), it could be in the form of a diagram and/or linked to the 
(TBC) lifecycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but 
at least proposing one can help understanding, as you wrote: "show how 
all the various drafts, protocols, and discussions in the ANIMA WG fit 
together".

Thanks, best regards, Laurent.

On 04/06/2015 15:18, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Jun 2015 15:59:25 +0000

inline...
From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 04 June 2015 16:56
To: Michael Behringer (mbehring); Anima WG
Subject: Re: [Anima] Next steps for the reference document

Hi Michael,

I am ok to contribute on the intent and section 8 - "coordination / conflict resolution" (as per draft-behringer-anima-reference-model-01), and section 9 - "Hybrid Approach with Non-Autonomic Functions".
MB: Thanks for volunteering!
For "constrained" AN nodes, I think they are in scope, but what is the implication for the reference model document? Do we already have some inputs/requirements (e.g. from other WGs or sources) that could enlighten how / to which extent autonomic networks / their functionalities and mechanisms shall (or not) adapt (to such constrained nodes)?
MB: I think we need to work out what is the minimum "useful" autonomic node, and specify what the requirements for those are. Personally I do not think we want to make every smallest sensor fully autonomic. I see three classes:

1)      fully AN capable (what we describe today)

2)      constrained AN capable: This will be a node that for example can be an edge, can use AN functions, but doesn't participate in many functions, only has stub functionality.

3)      non AN capable (according to our definitions here): Those can still implement something "autonomic" in their own understanding of the world, but it may or may not work with what we're doing here.
We need to consider nodes in 1) and 2). For 3) I would argue we'd require some gateway between two different models. None of this is set in stone, it's just my current thinking.

I am not quite sure what you meant by the "management angle"... I assume you are talking about the management/operations of the whole system (as if deployed by e.g. a network operator). if correct, then I think some aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this but would prefer to start with some group discussions to see if we agree on the scope first.
MB: Yes, that's what I had in mind. Thanks for volunteering. :)

A tricky (missing) part might be the relationships among the various component. If judged useful (I think it is especially for ANIMA "outsiders"), it could be in the form of a diagram and/or linked to the (TBC) lifecycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but at least proposing one can help understanding, as you wrote: "show how all the various drafts, protocols, and discussions in the ANIMA WG fit together".
MB: Yes, we should have such a diagram. Or diagram(s).
Thanks Laurent!
Michael

Points to address:

Michael

Anima mailing list

[email-masked]<mailto:[email-masked]>

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2015 14:24:56 -0400

Laurent Ciavaglia <[email-masked]> wrote:
    laurent> For "constrained" AN nodes, I think they are in scope, but what
    laurent> is the implication for the reference model document? Do we
    laurent> already have some inputs/requirements (e.g. from other WGs or
    laurent> sources) that could enlighten how / to which extent autonomic
    laurent> networks / their functionalities and mechanisms shall (or not)
    laurent> adapt (to such constrained nodes)?

I think that constrained nodes will always need be coordinated by
non-constrained nodes, and to the extent that we need to be able to deal
with transitivity in trust through the coordinator node, they are in scope.

There are really two aspects of constrained nodes as explained by rfc7228:
The nodes themselves (section 2.1) vs the network (section 2.2).

So, I don't think we need to design for nodes that are as small as Class 2
devices, and I also don't think that our ACP will be a "Challenged Network"
once constructed, but it could be that during the construction of the ACP,
that Challenged networks will be in scope.

(Imagine two BFR-routers with 100Gb/s fiber between them via a photonic
switch. They have to set up the ACP that includes the photonic switch via
802.11 or 802.15.4.  Once the photonic switch is configured correctly,
bandwidth is plentiful, but until then...)

Having said this, the role of "constrained node coordinator" may well be a
responsability that the AN will need to find.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Thu, 04 Jun 2015 20:14:03 +0000

Hi Michael.
I am willing to contribute with intent, conflict resolution, and management
topics.
Jéferson

Em qui, 4 de jun de 2015 às 10:18, Michael Behringer (mbehring) <
[email-masked]> escreveu:

> Thanks for all who volunteered to participate in the reference doc. While
> detailed discussions may be between the contributors, the main technical
> discussions should probably take place on the main list. Here, I summarise
> my view on what needs to be done in the reference document.
>
> The overall goal is to show how all the various drafts, protocols, and
> discussions in the ANIMA WG fit together.
>
> Points to address:
>
> -       We should have a short section on intent. Explaining ingest of
> intent, distribution, the nature (on top of what's in RFC7575). That intent
> is signed, time stamps, etc. Probably pointing back to RFC7575. (Note
> intent distribution is handled in section 7.3)
> -       Do we want to address "constrained" AN nodes, with limited
> capabilities, here? I think so... We'll need that for AN in constrained
> environments. This could go into a new section in section 3: "constrained
> network elements".
> -       The masa section needs to be written. The masa will be an optional
> element. Needs to point to the bootstrap draft, which explains the basics.
> -       Addressing section needs to bring in recent discussions. Needs to
> include how an ASA uses addressing. per node or per ASA. (I think we
> concluded per node).
> -       Domain certificate template. We should write a section on the AN
> domain certificate. How the various fields are used.
> -       Section 9 needs to be worked out. This is all about conflict
> resolution. Maybe we should re-name that section? RFC 7575 already mentions
> this. Maybe we don't need much more here.
> -       trust management: inside a domain, between domain and sub-domain,
> and between domains. This should become a new section.
> -       Need to treat the question of the "out of band" ACP versus the
> inline ACP. The two models both work, but there are implications, different
> benefits, drawbacks, etc. This needs to be explained.
> -       Routing: In the case of a virtually separate ACP, as in
> draft-behringer-anima-autonomic-control-plane, we need to also define a
> routing protocol (thinking of the discussion in homenet, this might be
> "fun"...)
> -       Security considerations need to be expanded. Threat analysis needs
> work; need general security considerations, talk about the PKI and trust
> model, etc.
>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Thu, 04 Jun 2015 20:19:59 +0000

Inline

Em qui, 4 de jun de 2015 às 12:59, Michael Behringer (mbehring) <
[email-masked]> escreveu:

>  inline…
>
> *From:* Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* 04 June 2015 16:56
> *To:* Michael Behringer (mbehring); Anima WG
> *Subject:* Re: [Anima] Next steps for the reference document
>
>
>
> Hi Michael,
>
> conflict resolution" (as per draft-behringer-anima-reference-model-01), and
> section 9 - "Hybrid Approach with Non-Autonomic Functions".
>
> inputs/requirements (e.g. from other WGs or sources) that could enlighten
> how / to which extent autonomic networks / their functionalities and
> mechanisms shall (or not) adapt (to such constrained nodes)?
>
> MB: I think we need to work out what is the minimum “useful” autonomic
> node, and specify what the requirements for those are. Personally I do not
> think we want to make every smallest sensor fully autonomic. I see three
> classes:
>
> 2)      constrained AN capable: This will be a node that for example can
> be an edge, can use AN functions, but doesn’t participate in many
> functions, only has stub functionality.
>
> 3)      non AN capable (according to our definitions here): Those can
> still implement something “autonomic” in their own understanding of the
> world, but it may or may not work with what we’re doing here.
>
> We need to consider nodes in 1) and 2). For 3) I would argue we’d require
> some gateway between two different models. None of this is set in stone,
> it’s just my current thinking.
>
>
> you are talking about the management/operations of the whole system (as if
> deployed by e.g. a network operator). if correct, then I think some aspects
> of lifecycle / phases/ operations should be considered / written in the
> document. I can contribute to this but would prefer to start with some
> group discussions to see if we agree on the scope first.
>
> MB: Yes, that’s what I had in mind. Thanks for volunteering. J
>
(Jéferson) I think it is also important to define/describe the management
interfaces supported by the ASAs and other ANIMA components.

> at least proposing one can help understanding, as you wrote: "show how all
> the various drafts, protocols, and discussions in the ANIMA WG fit
> together".
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jun 2015 14:44:05 +1200

Hi,

Somewhere, and I think it needs to be in this document, we should
IMHO outline the minimum capabilities of a device capable of running
an ASA. Just to mark out the territory with an example, I expect we're
agreed that light switches won't run ASAs, whereas the lighting
controller for one floor of a large building might do so (communicating
with other lighting controllers, the emergency evacuation controller,
and other ASAs using Anima signaling).

So, a section on device capabilities would help to make this more
concrete. For now, this section would probably be a placeholder.

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 5 Jun 2015 08:17:18 +0000

Good point, Brian, noted in my "to do list". 

Thinking out loud: Section 3 talks about various node types, and I suggest we also bring in constrained nodes here. That would then lend itself nicely to also discuss minimum capabilities. 

Actually, I don’t think I agree with your statement about light switches not having ASAs. 

The way things start to look in my brain: 
- Category A: devices too small to do anything AN
- Category B: constrained AN devices, that don't have all functions. For example, they may only have stub routing functions. 
- Category C: "full" AN nodes. 
- a light switch could be in either category, likely A or B, not C (pure guess). 
- if the light switch falls into A, it doesn't have an ASA, since it's not autonomic in our definition. 
- if it's in B, and I think this is the case you're talking about(?) THEN I think it also has an ASA to control the light. 

The ASA will be VERY simple: 
- if mechanical switch goes to "off", send a message to "all lights under my control": "turn Off"
- if mechanical switch goes to "on", send a message to "all lights under my control": "turn On"
- some way to learn which lights are under its control, some grouping of sorts. 

But to me, that *is* an ASA. It uses the Autonomic infrastructure, namely the message bus. 
(And, strictly speaking, the enrolment process (client side) is also an ASA. Which I think is probably mandatory) 

So, I think in practice EVERY device in category B or C will have ASAs, albeit in the simplest case just for enrolment. 

Thoughts? 
Michael

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 05 June 2015 04:44
> Somewhere, and I think it needs to be in this document, we should IMHO
> outline the minimum capabilities of a device capable of running an ASA.
> Just to mark out the territory with an example, I expect we're agreed that
> light switches won't run ASAs, whereas the lighting controller for one floor
> of a large building might do so (communicating with other lighting
> controllers, the emergency evacuation controller, and other ASAs using
> Anima signaling).
> 
> So, a section on device capabilities would help to make this more concrete.
> For now, this section would probably be a placeholder.
> 
> Regards
>    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 5 Jun 2015 08:21:08 +0000

(Jéferson) I think it is also important to define/describe the management interfaces supported by the ASAs and other ANIMA components. 

Agreed. I had that mentally stored in the bucket: 

Michael

---

From: John Strassner <[email-masked]>
Date: Fri, 5 Jun 2015 01:55:20 -0700

Agreed; I would like to generalize this into a set of:
   - requirements to be satisfied
   - capabilities to be advertised
   - constraints to be applied

I'm happy to work on this and other management sections.
Also happy to work on the connection between APIs and models.

best regards,
John

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 5 Jun 2015 09:30:47 +0000

> From: John Strassner [mailto:[email-masked]] 
> Sent: 05 June 2015 10:55
> To: Brian E Carpenter
> Cc: Michael Behringer (mbehring); Anima WG

Excellent, thanks John. 

I'm thinking how to slice and dice this document. The more I think about it, the current structure is not optimal. The registrar and MASA are really ASAs, and should be dealt with in a separate section. Then we could re-do section 3 like this: 

3. The Network Element
- Class 1: unconstrained autonomic nodes
- Class 2: constrained autonomic nodes
- Class 3: non-autonomic nodes

where each class describes the minimum capabilities (MUST implements, later on). 
On the constrained devices, Michael Richardson would be an ideal candidate to provide some text? Would you volunteer Michael? I'm thinking about mapping that nicely to the existing work, making sure it all fits together? 

And we take MASA and registrar into a separate section:
 
4. Specific Autonomic Functions
- Registrar
- MASA

To your point "capabilities to be advertised": Can you expand on that? I would assume that each base model has  a number of capabilities that are assumed. So a node would say "I'm class 1" - which includes a whole lot of base capabilities, right? Anything optional on top needs to be advertised separately. But - that's said in two sentences? 

To your point "constraints to be applied" - can you expand? 

MIchael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 5 Jun 2015 09:37:15 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: 04 June 2015 20:25
> To: Laurent Ciavaglia
> I think that constrained nodes will always need be coordinated by non-
> constrained nodes, and to the extent that we need to be able to deal with
> transitivity in trust through the coordinator node, they are in scope.
> 

That's for sure. Also what capabilities we expect in a constrained node may well evolve over time. But you know all the context in that space, can provide us with the right references, etc - as written in the other mail - would you help us with some text on the constrained nodes? 

Michael

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 5 Jun 2015 09:45:35 +0000

Hi Michael,

I'm glad to work on the following items: 
-	Naming section needs meat. What names are used for, where it is in the domain cert.
-	Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node).
-	Need considerations for APIs: How can ASAs use the ANI?

Best regards,
Bing

> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Behringer (mbehring)
> Sent: Thursday, June 04, 2015 9:19 PM
> To: Anima WG
> Subject: [Anima] Next steps for the reference document
> 
> -	We should have a short section on intent. Explaining ingest of intent,
> distribution, the nature (on top of what's in RFC7575). That intent is signed,
> time stamps, etc. Probably pointing back to RFC7575. (Note intent
> distribution is handled in section 7.3)
> -	Section 9 needs to be worked out. This is all about conflict resolution.
> Maybe we should re-name that section? RFC 7575 already mentions this.
> Maybe we don't need much more here.
> -	Need to treat the question of the "out of band" ACP versus the inline
> ACP. The two models both work, but there are implications, different

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jun 2015 09:24:41 -0400

Brian E Carpenter <[email-masked]> wrote:
    > outline the minimum capabilities of a device capable of running an
    > ASA. Just to mark out the territory with an example, I expect we're

    > concrete. For now, this section would probably be a placeholder.

"ASA functionality is not expected to fit into a class 2 or smaller device"
[RFC7228].

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jun 2015 10:55:31 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:

    >> constrained nodes, and to the extent that we need to be able to deal

    >> There are really two aspects of constrained nodes as explained by
    >> rfc7228: The nodes themselves (section 2.1) vs the network (section
    >> 2.2).
    >>
    >> So, I don't think we need to design for nodes that are as small as
    >> Class 2 devices, and I also don't think that our ACP will be a
    >> "Challenged Network" once constructed, but it could be that during the
    >> construction of the ACP, that Challenged networks will be in scope.
    >>
    >> (Imagine two BFR-routers with 100Gb/s fiber between them via a
    >> photonic switch. They have to set up the ACP that includes the
    >> photonic switch via 802.11 or 802.15.4.  Once the photonic switch is
    >> configured correctly, bandwidth is plentiful, but until then...)
    >>
    >> Having said this, the role of "constrained node coordinator" may well
    >> be a responsability that the AN will need to find.

    > That's for sure. Also what capabilities we expect in a constrained node
    > may well evolve over time. But you know all the context in that space,
    > can provide us with the right references, etc - as written in the other
    > mail - would you help us with some text on the constrained nodes?

I have read the reference model.
Can we adopt this already?

I suggest changing:
  MASA (Manufacturer Authorized Signing Authority): The MASA is a
      service for devices of a particular vendor.  It can validate the
      identity of devices that are to be used in an autonomic domain,
      assert which device is owned by which domain, etc.
to:
  MASA (Manufacturer Authorized Signing Authority): The MASA is an
      online service for devices of a particular vendor.  The MASA
      can validate the identity of devices that are to be used in an
      autonomic domain.  It can provide assertions as to the owner
      of a particular device.  The name/location of the MASA is built-in
      to the device at the Factory.

section 3.4: Constrained Nodes

Autonomic Service Agents are not expected to run or fit into class 2 or
smaller constrained nodes (see RFC7228).  If there are constrained nodes
that need to be involved in the Autonomic Control Plane, it is assumed that
they do so with the aid of a designated non-constrained node. (Finding and
electing an constrained-node helper is itself an autonomic function)

Constrained nodes do need to be able to join the network, and the trust
infrastructure (section 6) is expected to provide a transitive trust
mechanism such that constrained nodes can be helped in a secure way.

section 3.5: Challenged networks

In comparison to the production network (which may not yet be operational),
the Autonomic Control Plane could be considered constrained.  The bandwidth
differences may be on the order of a 1000x or more (100Gb/s production
networks compared to ACP bandwidths between 1Mb/s and 10Mb/s).  The resulting
ACP is considered slow, but should not in general be considered challenged as
defined by RFC7228.  As such, the ACP should significantly depreference LLNs
and other limited energy networks, but use of such networks during the
bootstrap of the ACP is in scope.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jun 2015 13:07:45 +1200

> smaller constrained nodes (see RFC7228). 

That makes a lot of sense to me (thanks, BTW, for introducing me to RFC 7228).

Especially if we take GDNP in the JSON direction, I don't see it on 250kB
devices, except maybe for a tiny subset.

> - some way to learn which lights are under its control, some grouping of sorts. 

Except that, for example, there might be a need for intent saying "ignore mechanical
switch iff evacuation_mode and not fireman_mode" or something. In other words
things can get complicated quite quickly, so RFC7228-class2 nodes are looking
like borderline cases to me.

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 9 Jun 2015 12:05:44 +0000

MichaelR, great guidance, thanks for that. Inline...

> Can we adopt this already?

You mean the reference model as a WG item? That's for the chairs to decide, but my personal target is to have it before Prague in such a shape that adoption should be unanimous. 
 
>       to the device at the Factory.

Yes, that's better. Actually, given past discussions on this subject I would also mention explicitly the possibility to just provide a history of the device. So, adding this to your paragraph would result in (my change in uppercase): 

 OR THE HISTORY of a particular device.  The name/location of the MASA is built-in

I'll change that in the doc. Does anyone else have comments here?  

> In comparison to the production network (which may not yet be
> operational), the Autonomic Control Plane could be considered
> constrained.  The bandwidth differences may be on the order of a 1000x or
> more (100Gb/s production networks compared to ACP bandwidths between
> 1Mb/s and 10Mb/s).  The resulting ACP is considered slow, but should not in
> general be considered challenged as defined by RFC7228.  As such, the ACP
> should significantly depreference LLNs and other limited energy networks,
> but use of such networks during the bootstrap of the ACP is in scope.

I think ... this discussion might be addressing the wrong problem. I think the primary question is not whether a node can run an ASA or not, because it assumes that the ANI is the same everywhere. 

To me, the main question is: Can we have a useful, reduced ANI implementation? 

I can see a constrained AN node, which for example can live at the edge only, doesn't support bootstrap proxy, full routing, etc, and who's ANI is therefore smaller. Possibly a different security model in the constrained network; etc. 

And then, a simple ASA on top of this reduced ANI. 

And, MichaelR, you *are* saying this, more or less. But I would formulate it the other way round, starting with the ANI, and really focusing on that: 

Constrained nodes have a reduced ANI, with a well-defined minimal functionality (details to be worked out): They do need to be able to join the network, and communicate with at least a helper node which has full ANI functionality. 

<--
you wrote at this point: ... and the trust infrastructure (section 6) is expected to provide a transitive trust
mechanism such that constrained nodes can be helped in a secure way.
... I don't understand what you mean with "can be helped".  You mean: If the NOC trusts the helper, and the helper trusts the constrained device, we're good, right? 
--> 

You wrote further: 

At this point, I would rather defined whether the (reduced) ANI fits into a class 2 device. Do you think we can make that happen? I would guess so? 

Once we understand what a reduced ANI means, and which nodes can run it, THEN I think we can start thinking about ASAs. And to my previous example of the light switch, I (still) believe that an ASA could be VERY small. So this is not the key question here, I think. 

So, in summary, I see: 
- full ANI
- reduced ANI: Probably we need to define exactly which functions we can expect in a reduced ANI. Ideally this would result in a single class. 
- ASAs that require the full ANI
- ASAs that can also run on a reduced ANI. 

Thoughts? (This is a good discussion!)
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jun 2015 08:03:40 +1200

On 10/06/2015 00:05, Michael Behringer (mbehring) wrote:
...
> Once we understand what a reduced ANI means, and which nodes can run it, THEN I think we can start thinking about ASAs. And to my previous example of the light switch, I (still) believe that an ASA…

The logic of an ASA could be very simple, if that's what you mean by saying
it could be very small. But indeed, the question is whether the footprint
of the supporting code could be very small. I'm far from convinced of that,
especially if we use a prolix format like JSON. However you reduce the
ASA functionality, you're going to need a certain set of components, like
 - minimal O/S
 - network stack
 - security stack
 - bootstrap logic
 - GDNP engine (which might require a JSON interpreter & CBOR encoder/decoder)
 - the actual light switch controller
and then you can get started with your ASA.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 10 Jun 2015 08:35:54 +0000

> Sent: 09 June 2015 22:04
> To: Michael Behringer (mbehring); Michael Richardson; Anima WG
> > Once we understand what a reduced ANI means, and which nodes can run
> it, THEN I think we can start thinking about ASAs. And to my previous
> example of the light switch, I (still) believe that an ASA could be VERY small.
> So this is not the key question here, I think.
> 
> it could be very small. But indeed, the question is whether the footprint of
> the supporting code could be very small. I'm far from convinced of that,
> especially if we use a prolix format like JSON. However you reduce the ASA
> functionality, you're going to need a certain set of components, like
>  - minimal O/S
>  - network stack
>  - security stack
>  - bootstrap logic

Right. That's what I mean - the constraint is more on the ANI side than on the ASA side. 

Can we estimate the minimal requirements for a constrained ANI, looking at the list above? 

One question we need to ask ourselves is whether we want to include the work on constrained nodes right now or push that back? If we understand the AN model for constrained nodes better, we can see whether there are any immediate use cases around for this, which might help us prioritize. 

Michael
 
>    Brian
> 
> > So, in summary, I see:
> > - full ANI
> > - reduced ANI: Probably we need to define exactly which functions we can
> expect in a reduced ANI. Ideally this would result in a single class.
> > Thoughts? (This is a good discussion!) Michael
> >
> >