peter van der Stok <[email protected]> wrote: > Michael Richardson schreef op 2017-11-10 19:41: >> {In some ways this should be a discussion among the authors of which I am >> now >> one, but I feel that the discussion belongs in public} >> >> 1) discovery. >> >> Section 4.1 provides for the process to start with a discovery operation. >> >> The presence and location of (path to) the management data are >> discovered by sending a GET request to "/.well-known/core" including >> a resource type (RT) parameter with the value "ace.est" [RFC6690]. >> Upon success, the return payload will contain the root resource of >> the EST resources. It is up to the implementation to choose its root >> resource; throughout this document the example root resource /est is >> used. The example below shows the discovery of the presence and >> location of management data. >> >> REQ: GET /.well-known/core?rt=ace.est >> >> I can see the architectural reasons for why we do that, but I really have >> to >> ask why if we really really need this extra round trip.
> This is the standard way of discovering coap endpoints.
> It's done once at start-up. It's extra to what?
Yes, once after a whole bunch of DTLS setup packets back and forth.
So perhaps it fades into noise compared to the DTLS setup...
>> The alternative is that we either have to use /.well-known/est, or that
>> we wind up standardizing something (maybe /e) that isn't inside
>> /.well-known.
>>
> I don't understand this last phrase,
We could go against some architecture decisions and standardize /e or
something like that rather than /.well-known/est or the lookup.
Given the size of the vouchers, the certificates being passed around by
DTLS, and the DTLS record format... does shortening the URLs from
/.well-known/est buy much? I shall look at the example packets in the
document to see.
Can the response from core?rt=ace.est be "/" or ""?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
