Brian, I began reading draft-carpenter-anima-asa-guidelines-00 and also
draft-liu-anima-grasp-api-01. (Chairs, I think they should become
WG items)
I think though, that section 3.3 of asa-guidelines ought to be worked into
the GRASP protocol document's introduction. (But should remain in
asa-guidelines as is, except for "kernel")
This would be some of the text that I suggested was missing that explains how
to use the different mechanisms. I haven't read -08 yet, mind you, so many
you got this already.
Let me tweak the text slightly below. I suggest
that the world "kernel" may be confusing to some developers: it may make them
think that GRASP requires access to toggle hardware bits...
3.3. Mechanisms offered by GRASP
GRASP is expected to run as an operating system core module,
providing an API (such as [I-D.liu-anima-grasp-api]) to interface to
less privileged ASAs.
Thus ASAs may operate without special privilege, unless they need it for
other reasons (such as configuring IP addresses or manipulating routing
tables).
The GRASP mechanisms used by the ASA are built around GRASP objectives
defined as data structures
containing administrative information such as the objective's unique
name, and its current value. The format and size of the value is
not restricted by the protocol, except that it must be possible to
serialise it for transmission in CBOR [RFC7049], which is no
restriction at all in practice.
The GRASP provides the following mechanisms:
o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA can
discover other ASAs
supporting a given objective.
o A negotiation request mechanism (M_REQ_NEG), by which an ASA can start
negotiation of an objective with a counterpart ASA. With this,
there is a corresponding negotiation response mechanism
(M_NEGOTIATE) mechanism for an ASA that
wishes to respond to negotiation requests, and a set of functions to
support negotiating steps (M_END).
o A synchronization mechanism (M_REQ_SYN), by which an ASA can request the
current value of an objective from a counterpart ASA. With this,
there is a corresponding listening function for an ASA that
wishes
to respond to synchronization requests.
o A flood mechanism (M_FLOOD), by which an ASA can cause the current value
of
an objective to be flooded throughout the AN so that any ASA can
receive it.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
