Esko Dijk <[email protected]> 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
