On 30/09/2017 06:24, Michael Richardson wrote:
>
> Toerless Eckert <[email protected]> wrote:
> > On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
> brian> Toerless explained elsewhere why he thinks the duplication is
> brian> needed.
> >>
> >> I read that after my email.
> >> I simply can't agree.
>
> > I don't think i was suggesting duplication. I was suggesting for
> > one document to define an extensibel objective and the other draft to
> > extend it.
>
> Objectives are so easy to define and require so little IANA coordination that
> I don't see why we would want to extend it without also updating the BRSKI
> document.
>
> So to be clear: this is overly general, and I am opposed to this.
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?
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.
3. If so, do we want to re-use the same objective (AN_join_registrar
for the sake of argument)? Or would we prefer this to be a distinct
objective?
(I don't think the question would be different in a DNS-SD regime:
one service or two?)
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.
There's no doubt this can be done; I've already checked that even
my prototype GRASP code can carry quite complex CBOR structures
transparently. But it does assume that the recipient ASA can
reliably parse them, which is a reasonably complex requirement
for AN infrastructure components.
I don't have preconceived answers to questions 1, 3 and 4. What
do people think?
Toerless also wrote:
> The extensibel notation i was suggesting would also result in the
> definition of a brski-enrol service name that would be useable outside
> of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.
I didn't quite get 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).
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
