Thanks Klaus. OK about waiting for confirmation on ports returned in discovery and RFC6690.
> wouldn't it also be possible to configure the client with the whole URI > containing the three parts directly? Yes, that is perfectly possible. I don't think the draft is forbidding the whole URL being configured instead of a host:port:ArbitraryLabel tuple. > I really don't see why the EST-coaps specification needs to provide examples > for basic CoAP features that don't play a crucial role in the application. Understood what you meant. I removed the normative "MUST" and replaced the language to more explicitly state the "RECOMMENDED" for implementers. > Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of > an option is intended to be this default value, the option SHOULD NOT be > included in the message." [1] So your example actually violates this 'SHOULD > NOT'... For consistency we now use FQDNs in all our /crt examples, so I think the A.1 is more justified. If you want to check the updated draft use https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt Rgs, Panos -----Original Message----- From: Klaus Hartke <[email protected]> Sent: Tuesday, March 05, 2019 8:45 AM To: Panos Kampanakis (pkampana) <[email protected]> Cc: [email protected]; Jim Schaad <[email protected]> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis wrote: > > 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. [...] I was aiming at something different, but, re-reading my question, my question wasn't very clear. Let me try again. In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to know the host name (or IP address) and port number of a CoAP server. It then constructs the URI <coaps://{host}:{port}/.well-known/core> and then gets a list of links to the EST resources. The host name and port number must come from somewhere -- e.g., from configuration or from some other discovery process. I'm quite happy with this. Then you were saying that, in some cases, this discovery step is unnecessary/wasteful. A client would instead need to know the host name (or IP address) and port number of a CoAP server as well as an ArbitraryLabel. It would then construct the URI <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen> and could immediately start interacting with that resource. Again, the host name, port number and ArbitraryLabel must come from somewhere. You were saying that they come from configuration. My question is: If host name, port number and ArbitraryLabel can come from configuration, from which the client constructs <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen>, wouldn't it also be possible to configure the client with the whole URI containing the three parts directly? > > 5.1 "Discoverable port numbers can be returned in the response payload." -- > > Now I'm wondering if that's actually permitted by RFC 6690... > > [...] but I think the example is OK to include the port. I'm not sure. RFC 6690 is really weird. Let me get back to you on this. > > 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. You're mixing up protocol specification and implementation guidance. On the protocol specification side, both clients and servers are free to choose if they want to use confirmable or non-confirmable messages. And an application should not make any restrictions on that. On the implementation guidance side, I think it makes a lot of sense to choose delayed responses here. But implementation guidance should be clearly marked as such, as not to create the impression that implementations can only use certain messages types or can rely on only certain messages types being used. > > 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. Yes, having more examples for reference is really nice. And I really like that you, the authors, spent quite obviously a lot of time making sure that EST-coaps is actually implementable and figuring out the best ways to implement it. But, as I said above, you're mixing up protocol specification and implementation guidance too much for my taste. I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application. Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'... Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.4.4 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
