Thanks Esko. Addressed in https://github.com/SanKumar2015/EST-coaps/blob/84ce0c1d5e768d40e97184214bae404da21bd050/draft-ietf-ace-coap-est.xml Two comments:
> page 11 bottom requirement: " The client SHOULD use resource discovery when > he is unaware of the available EST-coaps resources." - when an EST server is > known, this requirement does not really apply since the server always > supports .well-known EST resources. So I read it as doing an RD discovery or > multicast CoAP discovery if the client doesn't known the EST server address. > Hope this is clear enough in the text and intended? There are optional resources like /att, /skg and /skc that the server does not have to support, so that is what this sentence was referring to. > page 11 bottom: " It is up to the implementation to choose its resource > paths” -> seems not really the case, because the root resource structure is > forced by the specification. It could have been designed as free choice > (because it can be discovered anyway) but it is not. The text says that the server MUST support the default /.well-known/est root resource and it SHOULD support resource discovery for non-default URIs (like /est or /est/ArbitraryLabel) or ports. In the latter case it is up to the server to decide the paths he makes its resources available at. That is what this sentence was referring to. But you are right; I realized that this sentence is redundant so I only kept "Throughout this document the example root resource of /est is used." Will reupload the next iteration in a few days. Rgs, Panos -----Original Message----- From: Esko Dijk <esko.d...@iotconsultancy.nl> Sent: Monday, May 20, 2019 2:31 AM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org Cc: draft-ietf-ace-coap-...@ietf.org Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt Thanks, A few comments I had still on the discovery section - sorry to be late post-WGLC with this: - page 10 bottom mentions "management data" - should say "management resources", or "EST resources" perhaps? - page 10 bottom: " Upon success, the return payload will contain the root resource of the EST resources." - this is not true, since only the individual supported resources are returned. The root (e.g. "/est" in the examples) can be deduced from the response but it is never returned as one link format entry. - page 11 top: the example is only correct for a secure (coaps://) discovery GET request, I think this could be mentioned in text or indicated in the request line. - page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources. So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address. Hope this is clear enough in the text and intended? - page 11 bottom: "he supports" -> "it supports" - page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not. Best regards Esko -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis (pkampana) Sent: Friday, May 17, 2019 17:36 To: ace@ietf.org Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt Hi all, This latest update addresses feedback while in WGLC" - the comments by Hannes and Esko related to RNG and server-side key gen. It aims to prevent misunderstandings that random numbers are not needed any more if server-side key gen is used. - the nits with "/crt" instead of "/crts" pointed out by Esko. The diff is here https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11.txt Thanks, Panos -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org Sent: Friday, May 17, 2019 11:31 AM To: i-d-annou...@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-11.txt Pages : 48 Date : 2019-05-17 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-11 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
