Thanks again Klaus. We addressed your 2nd WGLC review comments in https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=%22Klaus+WGLC+review+2%2F27%2F2019%22 I think that is all of them. The latest version of the text is https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
We are planning to reupload this week, please let us know if there is more feedback. Below I am addressing the rest of your questions or things I didn't think needed an update in the draft. > But can't the client just be configured out-of-band with the URIs directly? That is right. We could mandate only .well-known URIs. But I think we ought to let a deployment use non-default URIs. For example some usecase might not want to send the .well-known in the URI to save transmission bytes and thus use a custom short URI. If the URI change takes place after deployment client will find that out with a discovery. Similarly, a usecase might initially not support one of the optional requests like server-side keygen. If the server adds support sometime in the future, the client could find out using discovery. And we ought to let the client be able to recover in case the well-known request URI fails for some reason and he wants to see what is supported by the server.That is why we thought it is still worth to keep the .well-known URIs along with the discovery. > 5.1 "The first three lines of the discovery response above MUST be returned > if the server supports resource discovery." -- ...if it supports EST? I mean, > if a server has a /.well-known/core resource and implements a draft, is there > a reason why it wouldn't include the EST resources in the /.well-known/core > representation? If it doesn't want to offer two sets of paths, it can simply > return this: > </.well-known/est/crts>;rt="ace.est.crts", > </.well-known/est/sen>;rt="ace.est.sen", > </.well-known/est/sren>;rt="ace.est.sren", > </.well-known/est/att>;rt="ace.est.att", > </.well-known/est/skg>;rt="ace.est.skg", > </.well-known/est/skc>;rt="ace.est.skc" Yes. The point of the "MUST" is that since crts, sen and sren are mandatory you are supposed to give them out when you support resource discovery for EST-coaps. If you are asking why don't we just support discovery and not the default ./well-known path, the reason that there might be cases where discovery is wasteful in terms of transmission and client code to parse the responses. These cases will never discover anything, they will just use the well-known path. > 5.1 "Discoverable port numbers can be returned in the response payload." -- > Now I'm wondering if that's actually permitted by RFC 6690... I saw <http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="describedby in a couple of examples in RFC6690. I also saw it in https://tools.ietf.org/html/draft-ietf-core-resource-directory that shows "Res: 2.05 Content <coap://[2001:db8:3::123]:61616/temp>;rt="temperature"; anchor="coap://[2001:db8:3::123]:61616" Jim suggested the anchor is not needed, but I think the example is OK to include the port. > 5.4 "All EST-coaps request messages expect an acknowledgement (with a > response payload); EST-coaps requests are confirmable CON CoAP messages." -- > This seems to be a matter of implementation quality and should not be a > requirement for interoperability. I suggest to remove this. We want to make use of Delayed responses. There are cases where the CA takes time to generate the cert/keypair, and in that case it needs to signal the delay with a Max-Age or Empty ACK. That is why we use CON. The text justification does not explain explicitly, but we didn't want to clutter the wording, so we kept it simple. > 7. "Parameters" -- This section should be a non-normative implementation note > or removed altogether. Yes, we removed all normative language from this section. > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't in > this example. Since it's not important for the example, maybe just remove > Uri-Host and Uri-Port from the example and also this paragraph? I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and port example online when I was searching and thus this is useful as a reference as well. Rgs, Panos -----Original Message----- From: Klaus Hartke <har...@projectcool.de> Sent: Wednesday, February 27, 2019 11:39 AM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com> Cc: ace@ietf.org; Jim Schaad <i...@augustcellars.com> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est Hi Panos, thanks for addressing all issues so thoroughly. I've performed another quick review of draft-ietf-ace-coap-est-09. 5.1. The discovery looks much better now! I think you had 5 or 6 ways for a client to construct or discover the URIs of an EST deployment. Now it seems there are only two: Either (A) the client is configured out-of-band with host name/IP address, port, and optionally an ArbitraryLabel and constructs a URI of the form coaps://{hostname]:{port}/.well-known/est/{optionally an ArbitraryLabel}/{one of the suffixes}. Or (B) the client is configured out-of-band with host name/IP address and port, constructs a URI of the form coaps://{hostname}:{port}/.well-known/core, performs a look up on that URI, and looks for a link in the response with a resource type of the form "ace.est.{one of the suffixes}". But can't the client just be configured out-of-band with the URIs directly? 5.1 "The ArbitraryLabel path-segment, if used, SHOULD be of the shortest length possible" -- So if someone decides to use an ArbitraryLabel path-segment consisting of more than 0 characters (which is the shortest length possible), then it's a protocol violation? This seems to be a matter of implementation quality to me, not a requirement for interoperability. 5.1 "(Sections 3.1 and 3.2.2 of [RFC7030]." -- Missing ) 5.1 "The EST-coaps server URIs, obtained through discovery of the EST-coaps root resource(s) as shown below, are of the form:" -- There is no longer a 'root resource' if a client discovers the full paths. For example, implementers are free to send the following /.well-known/core if they want: </the/quick/>;rt="ace.est.crts", </brown>;rt="ace.est.sen", </fox/jumps/over>;rt="ace.est.sren", </the/>;rt="ace.est.att", </lazy/dog?281>;rt="ace.est.skg", </lazy/dog?287>;rt="ace.est.skc" 5.1 "The first three lines of the discovery response above MUST be returned if the server supports resource discovery." -- ...if it supports EST? I mean, if a server has a /.well-known/core resource and implements a draft, is there a reason why it wouldn't include the EST resources in the /.well-known/core representation? If it doesn't want to offer two sets of paths, it can simply return this: </.well-known/est/crts>;rt="ace.est.crts", </.well-known/est/sen>;rt="ace.est.sen", </.well-known/est/sren>;rt="ace.est.sren", </.well-known/est/att>;rt="ace.est.att", </.well-known/est/skg>;rt="ace.est.skg", </.well-known/est/skc>;rt="ace.est.skc" 5.1 "The Content-Formats in the response allow the client to request one that is supported by the server." -- Maybe state explicitly that these are the values accepted by the server in the Accept option? 5.1 "Discoverable port numbers can be returned in the response payload." -- Now I'm wondering if that's actually permitted by RFC 6690... 5.1 " The client SHOULD use resource discovery when /.well-known/est fails" -- But if /.well-known/est fails, then the server clearly doesn't support EST because of "The server MUST support the default /.well-known/est root resource.", right? 5.1 "It is up to the implementation to choose its root resource;" -- As above, there is no root resource. 5.4 "All EST-coaps request messages expect an acknowledgement (with a response payload); EST-coaps requests are confirmable CON CoAP messages." -- This seems to be a matter of implementation quality and should not be a requirement for interoperability. I suggest to remove this. 7. "Parameters" -- This section should be a non-normative implementation note or removed altogether. A. "These examples assume a short root resource path of "/est"." -- As above, there is no root resource. Maybe the very first example in this section should be a look up of /.well-known/core for the URIs used in the following subsections? A.1 "Option Length = 0x9 Option Value = est-coaps.example.org" -- The value of 0x9 does not match the length of "est-coaps.example.org". Also in other examples and for other options. A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't in this example. Since it's not important for the example, maybe just remove Uri-Host and Uri-Port from the example and also this paragraph? A.2 "POST [2001:db8::2:1]:61616/est/sen" -- We don't have a standard format for CoAP examples, but this line uses a different format than section A.1. It might be good to make this consistent. Klaus _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
