I´m currently looking at the to do items in the reference model draft.  One 
thing I feel would add value is a state machine description of the various 
steps. It could explain how the various drafts fit together. I'm afraid we're 
not all on the same page here. So I drew up how I see the state machine for an 
ANIMA device, as a starting point, and how the drafts would link together:


The main states of an ANIMA device are "factory default", "enrolled", and "in 
ACP". BRSKI takes a device from "factory default" to "enrolled". Once 
"enrolled" the ACP draft explains how a device (now with a domain ID) would 
join the ACP for that domain. This draft explains how to get to the state "in 
ACP". Once a device is in the ACP, and (!) it sees a registrar (announced by 
GRASP), then it starts the bootstrap proxy.

The bootstrapping state machine is being worked on in the bootstrap design 
team. Let's leave the details of that one in that design team for now. (I sent 
a mail on Friday to that list with another state machine, if you're interested).

But my question to the team: Do you have the same view? (modulo the precise 
naming of particular states). Did we all agree that we'll discover ANIMA 
neighbors through mDNS? (I thought so). That we use GRASP in the ACP to find a 
Registrar? (Thought so, too).

Also the separation between the drafts - does that correspond with your view?


Anima mailing list

Reply via email to