Fries, Steffen <[email protected]> wrote: >> Can you explain to me why the discovery via /.well-known/brski is >> useful? This is on the *REGISTRAR*.
> The intention was to let the pledge or the pledge-agent know in advance
> what enrollment options are available at the registrar side allowing
> the pledge to fail fast if it does not have a matching enrollment
> protocol.
I understand this need, but it seems that we are making the pledge more
complex in order to keep the registrar simpler. That makes no sense to me:
the pledge should be minimal, while the registrar can remain complex.
>> In reading BRSKI-AE, I seem to be missing any place where the PUSH
>> mechanism is described. In a PUSH use case, what protocol would the
>> pledge expose to the pledge-agent and/or commissioner?
> This is currently left outside in terms of the protocol. The intention
> was to only specify the necessary (signature wrapped) data objects to
I'd really like to have the PUSH part in scope.
I thought that it was just not done yet, but it seems to me that without the
PUSH part, that the protocol isn't async at all. It is just BRSKI-CMP.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
