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