{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.
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.
Can DTLS compression do better things for us instead?
2) DTLS and HelloVerifyRequest.
SHOULD CoAP-EST servers always perform the HelloVerifyRequest state?
Again, it's an extra round trip.
Always doing it would simplify the code paths on both ends.
--
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
