> -----Original Message----- > From: Anima [mailto:[email protected]] On Behalf Of Brian E > Carpenter > Sent: 21 June 2016 04:53 > To: Anima WG <[email protected]> > Subject: [Anima] Question about ASA versatility > > Hi, > > The authors of the GRASP API draft have been talking (new version coming > soon) and there is one point where we have a question to the WG. > > Put simply: Does each ASA support only one objective, or can an ASA support > multiple objectives?
Define "objective"? If you mean objective as in the parameter / field in GRASP, I think the answer is that it can support more than one. To me, an autonomic function, consisting of various ASAs, is a distributed process that does something useful on the network. This can have simple functionality such as a parameter negotiation between various entities (in this case, it may be a single objective), or something much more complex, where many different things need to be negotiated. Somehow I think I don't understand your question :-) > And linked to that, if an ASA supports an objective for negotiation, must it > act > as both an initiator (client) and a responder (server), or can it have only > one > of those roles? Whatever the function requires it to do? (Again, I have the feeling I'm missing the point). > (The same question arises for synchronization objectives.) > > Some draft text from the API says the following, but is it right? > > An assumption of this API is that ASAs may fall into various classes: > > o ASAs that only use GRASP for discovery purposes. > > o ASAs that use GRASP negotiation but only as an initiator (client). > > o ASAs that use GRASP negotiation but only as a responder. > > o ASAs that use GRASP negotiation as an initiator or responder. > > o ASAs that use GRASP synchronization but only as an initiator (recipient). > > o ASAs that use GRASP synchronization but only as a responder and/or > flooder. > o ASAs that use GRASP synchronization as an initiator, responder and/or > flooder. > > The API also assumes that one ASA may support multiple objectives. > Nothing prevents an ASA from supporting some objectives for > synchronization and others for negotiation. Yes, the above makes sense to me, but why is that a question? Michael > Regards > Brian > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
