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

Michael Richardson <> Wed, 07 August 2019 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 475EB120437 for <>; Wed, 7 Aug 2019 09:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XvQbZg5X03Pr for <>; Wed, 7 Aug 2019 09:45:49 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 365C1120689 for <>; Wed, 7 Aug 2019 09:45:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C297380BE; Wed, 7 Aug 2019 12:45:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id C76743F; Wed, 7 Aug 2019 12:45:46 -0400 (EDT)
From: Michael Richardson <>
To: Brian E Carpenter <>
cc: "" <>
In-Reply-To: <>
References: <5523.1565112243@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 07 Aug 2019 12:45:46 -0400
Message-ID: <4937.1565196346@localhost>
Archived-At: <>
Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Aug 2019 16:45:53 -0000

Brian E Carpenter <> wrote:
    > 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
    > 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?)

I see some of the confusion.
poll(2) is a poorly named system call (that replaces select(2)), which
retrieves the next event from the kernel.  It doesn't really poll :-)

I think that the important point is that:
1) you can't see events in the queue.
2) you can't ask of an action is done, only find out that it finished.

    >> 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."

Good, we agree.
The GRASP library should create and manage these handles.
Nonce is the wrong term and will be confused with the protocol and
cryptographic things; handle is a better term.

    >> 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.

The age limit means that I never explicitely flush, thus ASA-1 doesn't mess
with the cache for ASA-2.

    >> 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.

In a threaded environment, I really want a thread per negotiation.
That means, on the server side (the side giving out resources), that I
need a thread per client, which means something has to spawn off these

    >> (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.

Not a bad idea, just an idea that must be clearly defined.

    >> 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 the API has to perhaps return something that says to the ASA, "new
negotiation here", rather than attempting to actually ever do anything.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-