Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

[Esko Dijk <[e-mail]>]

> This implies that a server is not required to support /.well-known/est We are not clear about this.  I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery.

Agree that the server MUST always support the /.well-known/est resource, since that's the resource that by definition is used for use cases where discovery is not viable.  So if a failure on that resource ought to trigger a discovery action, that would contradict its purpose.

Best regards
Esko Dijk

-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Michael Richardson
Sent: Thursday, January 24, 2019 16:59
To: Panos Kampanakis (pkampana) <[e-mail]>; [e-mail]
Cc: Jim Schaad <[e-mail]>; [e-mail]
Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07


https://goo.gl/LT4HYh  is a diff from -06 to current.
Panos has done a great job updating this according to the issues raised during the WGLC. Thank you

I have re-read diffs to catch up, and have these minor author tweaks/questions.

> Client authentication via DTLS Client Certificate is mandatory.

I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z"

s/enrolment/enrollment/   <- use American spelling, I guess. We had both.

section 6:
        REQ: GET /.well-known/core?rt=ace.est*

I didn't know the trailing "*" was a thing.
  </est>; rt="ace.est",

I guess I have to re-read the Core Link resource discovery document.
Can a server respond with </>; ?? it's shorter, and I think would be valid?

>  If
>                        the default root resource requests fail, the client
>              SHOULD fall back
>                        to doing a resource discovery.  Resource discovery
>              SHOULD be employed
>                        when non-default URIs (like /est or
>              /est/ArbitraryLabel) or ports are
>                                      supported by the server or when the
>              client is unaware of what EST-
>                        coaps resources are available by the server.

This implies that a server is not required to support /.well-known/est We are not clear about this.  I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery.


--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-