ANIMA WG,
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: [cid:[email protected]] 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? Michael
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
