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

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Nov 2017 13:41:02 -0500

{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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Sat, 11 Nov 2017 13:46:46 +0100

Hi Michael,

See below.

> 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?

> we wind up standardizing something (maybe /e) that isn't inside 
I don't understand this last phrase,

Peter

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Nov 2017 13:32:29 -0500

> 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...

    > 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 ""?

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Nov 2017 21:32:04 -0500

> Section 4.1 provides for the process to start with a discovery

...

    > 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.

Having read rfc6690 over again in order to implement this, I am now further
convinced that using this mechanism as a way to shorten the /.well-known/est
to something else is not entirely right.

I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to
return a list of hosts that support EST, and that EST ought to be returned in
a list of supported interfaces.

I'm less convinced that we ought to be using this mechanism to shorten
/.well-known/est to /est (why stop there? can't we go to /?)
It seems like maybe a 301-like (Moved Permantly) reply from
/.well-known/est/*, but CoAP doesn't have 301 codes....

(weird to me that rfc6690 got published with an informative reference to CoAP,
as WIP... I guess the WG wanted to get it out. I wish our process would let
us update that reference to the RFC, because it confuses the rfc dependancy
process)

    > Again, it's an extra round trip.  Always doing it would simplify the
    > code paths on both ends.

    > --
    > Michael Richardson <[email-masked]>, Sandelman Software Works -=
    > IPv6 IoT consulting =-

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Nov 2017 14:16:00 +0100

> /.well-known/est/*, but CoAP doesn't have 301 codes....

/.well-known/core is supposed to contain links.
The links point to resources which can be at the host themselves or at 
other hosts.

The example link for the resource with rt=ace.est is /est in the draft.
Anything else than /est can be used; the chosen path name is SDO- or 
installation dependent.

Indeed table 1 proposes to shorten the path names to the resources; 
these have received the same resource type (rt) in the discovery request 
half a page later.
One could make them discoverable with different rt's. In the latter 
case, these rt's need to be registered and the path names become 
discoverable.

Hope this clarifies.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 23:38:32 +0800

> /.well-known/est to /est (why stop there? can't we go to /?)

Why do you think that a node can only have one EST endpoint?
It should be possible to have many, and the client should be able to choose the one that is actually doing the right thing for them.

> /.well-known/est/*, but CoAP doesn't have 301 codes….

(The link-format self-description is exactly the replacement for the HTTP 301 here.  Same number of roundtrips...)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 21:57:17 -0500

> Why do you think that a node can only have one EST endpoint?

It could have hundreds, I agree.
Could also have hundreds of different IPs in the /64 answer.

If it had more than one, then shortening would have to be done differently
for each, I think.

We already have /.well-known/est as well.

    > It should be possible to have many, and the client should be able to
    > choose the one that is actually doing the right thing for them.

I'm pretty sure that I have no way to describe the logic to a client.

    > (The link-format self-description is exactly the replacement for the
    > HTTP 301 here.  Same number of roundtrips...)

yes, that's a good point, except that for the end-point that has the single
end point at /.well-known/est, then there is no 301.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 15 Nov 2017 03:16:44 +0100

Hi,

Jim suggests to keep both the /.well-known/est/* entry-points and the 
optional short ones.
Seems the right approach to me and gives the application the opportunity 
to shorten the request URIs.

Michael Richardson schreef op 2017-11-14 03:57:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Nov 2017 15:36:21 -0500

peter van der Stok <[email-masked]> wrote:
    > optional short ones.  Seems the right approach to me and gives the
    > application the opportunity to shorten the request URIs.

I agree.
Do you think that est/requestvoucher should also be shortened to ../est/rv?

I'm using the CoAP server rails plugin, "david"; I'm trying to add the ?rt=XXX
mechanism to it.  As is, it actually returns a value for every single defined
target:
I.e. it returns
     </.well-known/est/requestvoucher>,</.well-known/est/voucher_status>,<...>

I attempting to fix this.