On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this well written document. I have a couple of small DISCUSS > points and a few minor comments/questions that I would like to discuss. > > DISCUSS: > > 5.4. Message Bindings > > o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > Format, Block1, Block2, and Accept. These CoAP Options are used > to communicate the HTTP fields specified in the EST REST messages. > The Uri-host and Uri-Port Options can be omitted from the COAP > message sent on the wire. > > The statement above > > When omitted, they are logically > assumed to be the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are > typically used when an endpoint hosts multiple virtual servers and > uses the Options to route the requests accordingly. > > and the last quoted statement: How can the sender know whether or not it is Ok > to omit Uri-Host/Uri-Port?
How do you know when you need to send SNI to a TLS server? "If you try without and get a strange certificate back." I think that a similar situation is possible here, though of course you may just know from out-of-band configuration. > 7. Parameters > > It is recommended, based on experiments, > to follow the default CoAP configuration parameters ([RFC7252]). > However, depending on the implementation scenario, retransmissions > and timeouts can also occur on other networking layers, governed by > other configuration parameters. When a change in a server parameter > has taken place, the parameter values in the communicating endpoints > MUST be adjusted as necessary. > > The last sentence: use of MUST with passive voice is really unhelpful here. > Adjusted by whom? How can this MUST be satisfied? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Comment: > > 5.1. Discovery and URIs > > Clients and servers MUST support the short resource EST-coaps URIs. > > Just to clarify: the original EST URIs are prohibited in COAP-EST? My understanding is that the servers also have to support the original (long) EST paths. -Ben > In 5.8: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key which is encrypted by the client-defined (in the CSR) > > I would break up this sentence into 2 to make it clearer, as I initially read > this as 2 encryption operations applying to the generated private key itself. > So I suggest something like: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key. The symmetric key itself is encrypted by the client-defined > (in the CSR) > > asymmetric public key and is carried in an encryptedKey attribute in > a KeyTransRecipientInfo structure. > > Finally, if the asymmetric > encryption key is suitable for key agreement, the generated private > key is encrypted with a symmetric key which is encrypted by the > client defined (in the CSR) asymmetric public key and is carried in > an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. > > As above. > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
