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

Hi Michael,

That seems like a good idea. I think there might be an element of
redundancy but maybe that is not such a bad thing.

Regards
   Brian

On 20/10/2016 01:37, Michael Richardson wrote:
> 
> 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+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 