Subject: Re: [Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Oct 2017 20:24:44 -0400

Brian E Carpenter <[email-masked]> wrote:
    > So there are several separate questions here.

    > 1. I understood Toerless to be arguing that the registrar may need to be
    > contacted again some considerable time after the bootstrap (i.e. join)
    > action, specifically for what he called EST-renew.

    > Is that agreed?

Yes, but once on the ACP, a node has many different ways to find a renewal
Registrar.  Where that system is could be found via a number of other ways.

    > 2. If yes, would that need a new discovery action?

    > I assume the answer is yes, since we want to be reasonably
    > stateless and not assume that we can cache the registrar's address
    > and port indefinitely.

Yes.

    > 3. If so, do we want to re-use the same objective (AN_join_registrar
    > for the sake of argument)?

No, because:
  a) The join registrar might not support renewal or other complex
     EST methods.  This might be to avoid providing unnecessary attack surfaces.

  b) The join registrar may be provisioned for the join process.
     It might be turned off (or scaled down) when there are no nodes expected
     to join.

    > 4. In any case, do we want to make this objective or objectives
    > highly extensible (which basically means using CBOR maps instead
    > of simple CBOR arrays)? This has the usual pros and cons:
    > highly extensible = more complex parsing.

I don't want to do that.

    > Although we currently require that GRASP
    > runs over an ACP, there is nothing magic about that. I don't see that
    > BRSKI actually depends on the ACP either; both would surely run over
    > bare metal if we told them to (and the Security ADs weren't watching).

Agreed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Oct 2017 16:24:15 -0400

Brian, I was thinking after my BRSKI update email about M_FLOOD vs
M_DISCOVERY objectives.  I wondered if they were in the same IANA registry.

So I looked it up, and the answer is that they are, and that's as it should be.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Oct 2017 13:06:58 +1300

> So I looked it up, and the answer is that they are, and that's as it should be.

Yes. I think we can expect some fluidity in the semantics of objectives.
We say in GRASP that an objective can be both unicast-synchronized and flooded.

We also say that an objective cannot be both synchronized and negotitiated.
I'm not sure that restriction is really needed, but it's something that can
be relaxed later if we want.

    Brian