Re: [Ace] some thoughts about vanderstok-ace-coap-est

[Michael Richardson]

peter van der Stok  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] some thoughts about vanderstok-ace-coap-est

[peter van der Stok]

Hi Michael,

See below.

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?



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,

Peter

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace