Re: [Anima-bootstrap] agenda and details for Tuesday

Michael Richardson <> Wed, 01 March 2017 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BFBE1295D7 for <>; Wed, 1 Mar 2017 08:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 nDKxBlga3xjb for <>; Wed, 1 Mar 2017 08:31:41 -0800 (PST)
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 CEA911295C9 for <>; Wed, 1 Mar 2017 08:31:41 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 05ECAE1EE; Wed, 1 Mar 2017 11:53:59 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id DA1E26381A; Wed, 1 Mar 2017 11:31:40 -0500 (EST)
From: Michael Richardson <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.6+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, 01 Mar 2017 11:31:40 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima-bootstrap] agenda and details for Tuesday
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Mar 2017 16:31:47 -0000

Brian E Carpenter <> wrote:
    >> And this led me to thing that the Registrar discovery probably needs a full
    >> NEG_SYN, rather than M_FLOOD or M_DISCOVER...

    > You could do both. Use Flood as the baseline and Negotiate or
    > Synchronize if the baseline info is insufficient.

Please remind me if I've gotten the flow wrong, I just re-read section 3.8.4
and 3.8.5 and 3.8.6 of grasp-09.

Does it go:
     Proxy             Intermediate        Join Registrar

                              <---- unicast----  M_RESPONSE (I'm here)

        <----unicast---- M_RESPONSE (he is there)

     M_REQ_NEG ---------unicast----------------->

that is, the intermediate is just caching the location of the Join Registrar,
and really if we want to do negotiation, we should do it directly?

In this context, I don't see much difference, as you say, between M_DISCOVERY
vs M_FLOOD, except for when it occurs and the need to keep the cache of
things around.  In either case, the locators that we were discussing ought
really to only tell the Join Proxy where to find the Join Registrar's
grasp daemon, not where to find the registration system itself.

    > I'm not sure if GRASP is Turing-equivalent, but I think you
    > can probably do anything you want.

ha. I await the HAL9000 GRASP objective to be defined.

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