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