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

Brian E Carpenter <> Wed, 07 August 2019 02:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D64C5120091 for <>; Tue, 6 Aug 2019 19:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QE7j5K1ZMw8z for <>; Tue, 6 Aug 2019 19:28:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DE5312000E for <>; Tue, 6 Aug 2019 19:28:38 -0700 (PDT)
Received: by with SMTP id m9so38500342pls.8 for <>; Tue, 06 Aug 2019 19:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ik3j6PXFqxUBQwuvzr+jHwcEPC5rwL+jqAtLuW0uJl4=; b=sB2h1hUUl5irM8/fCLkTaBRg/bUf4xomC/ErOYH9tv8L/UB72UKLpIq6X7T085btP1 +FbveBe2nQ0SKcNcOYNLtpsJBRkPyTQEdlMq6QB99n48F3Rx4CW7acyUQoohvtJeDDnV 5Kq9VOUW2RvIyhSxtrLWjy/jrHNp7Qc6/bPM/vPCWWX82M0K2nDnF31Dyd9teZonlasw tLseEYcRrmuF474nYM1+5ze51FRVfmKq2PgObead9nYwTHxQJ0nWKtLMBfejyQutdcl7 WNbYa1XgiykaUX2hgy3LhtKjH5a2vzNhgRsJcXy0XNwZychZHpmh1rSLrZdaLHMiaygL 4Cwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ik3j6PXFqxUBQwuvzr+jHwcEPC5rwL+jqAtLuW0uJl4=; b=a03D4DFvoFWkMCE732wAe3PHUe64Gdc30LD+mgHiZBajQU3JS9M0H0v86cSvQqYdmD u91KSyh22Hc2lKCqwXuciHb1ddHk4x5wzscM3xmPdKMl+PeJi8AI/B2Jer6I18VmKUjy ni7ee2E4jCJ1VlklZX8mrWsbvfDVwp1x18qww3R+uSGZzRg3z/DFarQCe6mkNjjHypXl PUPD1erLH3yqUYfnqCFx1m9BXZAukb+9NgybQTbuBa4nPJQ1Q7oZJYGZxf9N1UPDET9i IwMD2PP5MNrQkHNPoSb9/RnufPMWX/1ernqAFLbJal8MQcJwL6AGd+ZcP+Et64bTV+1c hIlA==
X-Gm-Message-State: APjAAAUBB5TiTLRpefrrw0EXaTG88DcW1Zj90Ozm1pquOxvHr0o0azMf rVUFxLShGheqh+W99tgSxBQIvUSwG9w=
X-Google-Smtp-Source: APXvYqy/l5LUVwice/LIh7jz5UkWcdHdCjzf+8jtYhFt/PMqXEV3JfpiwdyvySXsmeLzInUnu0Lgzg==
X-Received: by 2002:a17:902:4683:: with SMTP id p3mr5574027pld.31.1565144917496; Tue, 06 Aug 2019 19:28:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u6sm20924456pjx.23.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 19:28:36 -0700 (PDT)
To: Michael Richardson <>, "" <>
References: <5523.1565112243@localhost>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 07 Aug 2019 14:28:31 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5523.1565112243@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 02:28:41 -0000

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
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
> If you are going to insert C structures, why not use a real example?
>   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

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


>          While I do not object, I do not see great utility in this document.
> nits:
> 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 <>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> _______________________________________________
> Anima mailing list