Re: [Anima] comments on draft-ietf-anima-grasp-api

[Brian E Carpenter <[e-mail]>]

Thanks very much Michael. Some partial responses below.

On 07-Aug-19 05:24, Michael Richardson wrote:
> 
> I read draft-ietf-anima-grasp-api from the expired drafts list.

Right, the -03 draft expired while we were in Montreal. Our plan
is to make the next update after the two promised reviews arrive.

> I think that the event-loop architecture is different than a
> polling architecture.  I agree that given an event-loop architecture,
> that one can build a polled architecture, but the converse is not true.
> The event-loop mechanism needs something to send events, while the polling
> system does not.

My understanding is limited, but the diagram at
https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
seems to say something different: the loop detects events by
polling. (Yes, OK, that's talking about Javascript but the
fundamentals are the same, surely?)

> section 2.3.1.3:
> If you are going to insert C structures, why not use a real example?
>   https://github.com/PJK/libcbor/blob/master/src/cbor/data.h#L164
>   cbor_value -> cbor_item_t

Yes, we can look at that. There are various CBOR libraries in C.
 
> I don't understand what the asa_nonce is for.

OK, then we need more text.

> Is this something that the underlying GRASP library is supposed to use
> internally to sort out which ASA is which?  Maybe this should be
> either a UUID, or an opaque type, which might in some cases, be a file
> handle, or contain one. (a la FILE *)

Yes, it should probably be opaque. In fact the documentation of the
concrete Python API says so: "Note - the ASA must store the asa_nonce
(an opaque Python object) and use it in every subsequent GRASP call."

> 
> 2.3.3 Discovery.
>   1) I would prefer to be able to ask for the list of cached
>      locators for an objective directly.

OK, I can see that might be useful.

>   2) Rather than flush them explicitely (because there might be
>      other ASAs depending upon them), I'd like to do a discovery
>      that asks for objectives that are at at most X miliseconds old.
>      Flush is therefore X=0.

Hmm. I think we assumed you would only flush if you had reason to
believe they were stale. But certainly adding an age limit seems
reasonable.

>   3) In both threaded and event-loop situations, I'd like to be able
>      have a function called when there are new answers, otherwise,
>      I have to poll.

Right, that's a callback in event loop terminology. It's a matter of
preference; I have an aversion to side effects so I don't like callbacks.
However, you're probably right that it should be an option.

>      (And, if a function is called, then the question as to which
>      thread does the calling is important; specifically one needs
>      to know which other functions one call at that point
>      answer may well be none. The answer depends upon how locking
>      of structures is done. The answer is easier in event-loop
>      version)

Yes; callbacks are a Bad Idea in a multithreaded version.
 
> 2.3.4 Negotiation.
>       Since the session_nonce is returned by the function, how
>       can the dryrun/run ever be mixed in a single session?  maybe
>       I don't know what a session is.
>       Ah, it's a value/result parameters.   So, please put it into
>       the input section too.

OK will think about that.

> 
> listen_negotiate.
>       I think that this call is wrong in both threaded and event-loop
>       use.  I think that in threaded version, I really want a new
>       thread spawned off that does the right things (negotiate_wait, etc.),

You do need a new thread. But I don't have time right now to explain
how that works in my example use cases. And my explanation would
be Pythonesque.

>       so I want to provide a function for that thread to run the negotiation.
>       In event-loop, I think that I want the same thing, but in the
>       function, I can't do synchronous calls, so the function has to
>       be called each time.

Sure. You have to insert a new event in the loop for each new negotiation.

> negotiate_step:
>       It says:
>          Threaded implementation: Called in the same thread as
>          the preceding 'request_negotiate' or 'listen_negotiate', with the
>          same value of 'session_nonce'.
>       but if it's in the same thread as listen_negotiate(), then I can
>       only handle negotiation with a single peer in that thread, I think?

Yes. Threads galore. A new thread for each new negotiation.

>       and I don't think I'd want to call listen_negotiate() for the
>       same objective.

Actually that will depend on the use case, but if you do so, you need
locks and atomicity. I put all of that into the prefix assignment demo,
I think.
https://github.com/becarpenter/graspy/blob/master/pfxm3.py 
> negotiate_wait: no idea why I'd use this.

That simply refelects a GRASP feature: tell the other end to wait longer.
> 
> Summary: I do not object to this document going forward as Informational, as
>          it represents an explanation of one implementation, and that is
>          what Informational is about.

All the same, I'd like to capture as much generality as possible.

>          It would be nice to have the view of multiple implementators, but
>          there is no energy for that.

Yes, that's what we need.

Regards
     Brian

>          While I do not object, I do not see great utility in this document.
> 
> nits:
>   2.3.1.3: s/neg/negotiate/
>   I found the "NEG" term in GRASP confusing, because it seems like
>   NEGative, rather then NEGotiate.  I'd prefer it was spelt out in
>   the API.
>   s/dry/dryrun/
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>