[Anima] text for grasp-07 (-08)

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-