To remove confusion, Pledge is used throughout the document.
Peter
Michael Richardson schreef op 2021-06-23 22:15:
Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
Figure 3: "EST client" -> this should be the Pledge. Which does BRSKI
bootstrap first, and then EST. Naming it only "EST client" sounds too
narrow.
Hmm.
It definitely the pledge until the voucher has been verified, and the
provisional (D)TLS connection has been verified. Probably until after
the
voucher-status POST.
At which point, ... it's really a verified EST client, and since
renew loops back to this point... calling it the EST client also makes
sense.
Maybe "EST pledge client" or some merging of terms?
For WG discussion: why isn't CoAP re-used to transport this CBOR
payload to the Registrar without having to define a new protocol?
(One answer could be that using CoAP will add much more bytes as
overhead, e.g. to encode a URI path. And the URI path of the
Registrar's "join-proxy resource" would have to be discovered also,
not
just the port. )
I think another answer is because the server side won't be CoAP, it's
DTLS
with a bit.
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
