Hi Hannes, Thank you. Let me try to address some of your questions.
> This sounds like a lot of constraints and I wonder whether this focus is just > a result of your personal interest or whether you believe this work cannot just be a new transport for EST. EST is used in ANIMA's BRSKI used for bootstrapping endpoints. We have a few usecases that call for running EST/BRSKI over COAP as an consistent common protocol in some constrained environments. So that is how this draft was started. > Do you believe that those two features are the ones that should be mandatory > to implement or is there less? Is there more? cacerts, enroll, reenroll and ANIMA BRSKI's voucherrequest, voucher_status are probably going to be the MTI. > How much text from other RFCs should be replicated in this document, > particularly from the EST RFC? Good point. We should clean up repetitions from other drafts. > Wouldn't it be useful to refer to RFC 7925 instead of writing new text for > the use of DTLS security? Good point. There will be some more EST related DTLS explanations (for example POP) in the next iteration, but leveraging RFC7925 and clean up overlapping text is also important > Do you have some early implementation experience with the suggested approach? Indeed. The Nexus Group and SICS have an initial implementation. Rgs, Panos -----Original Message----- From: Ace [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: Monday, January 23, 2017 3:10 AM To: [email protected] Subject: [Ace] draft-vanderstok-core-coap-est-00 Hi Peter, Hi Sandeep, thanks for putting this document together. I read through it and have some high-level questions regarding the envisioned scope and purpose of the document. The abstract, the introduction and the references suggest that the proposed mechanism is suitable for an IEEE 802.15.4 mesh network using 6lowpan in context of ANIMA using public key-based crypto only. This sounds like a lot of constraints and I wonder whether this focus is just a result of your personal interest or whether you believe this work cannot just be a new transport for EST. EST itself makes many of the features of the protocol optional already and there are essentially only two functions that really have to be implemented, namely * Simple PKI messages (using PKCS#10) * CA certificate retrieval Do you believe that those two features are the onces that should be mandatory to implement or is there less? Is there more? How much text from other RFCs should be replicated in this document, particularly from the EST RFC? Wouldn't it be useful to refer to RFC 7925 instead of writing new text for the use of DTLS security? Do you have some early implementation experience with the suggested approach? Ciao Hannes _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
