From 70eced51678c2ee05dd901f1688a4fa968215d36 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 12:56:09 +0100 Subject: [PATCH] Early mentioning of the optimization properties. --- draft-ietf-core-oscore-edhoc.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 85cd12f..c428ddb 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -81,6 +81,8 @@ This optimization is desirable, since the number of message exchanges can have a Without this optimization, it is not possible, not even in theory, to achieve the minimum number of round trips. This optimization makes it possible also in practice, since the message_3 of the EDHOC protocol can be made relatively small (see {{Section 1.2 of I-D.ietf-lake-edhoc}}), thus allowing additional OSCORE-protected CoAP data within target MTU sizes. +The minimum number of two round trips can be achieved only if the default, forward message flow of EDHOC is used, i.e., when a CoAP client acts as EDHOC Initiator and a CoAP server acts as EDHOC Responder. The performance advantage of using this optimization can be lost when used in combination with Block-wise transfers {{RFC7959}} that rely on specific parameter values and block sizes. + Furthermore, this document defines a number of parameters corresponding to different information elements of an EDHOC application profile (see {{web-linking}}). These can be specified as target attributes in the link to an EDHOC resource associated with that application profile, thus enabling an enhanced discovery of such a resource for CoAP clients. ## Terminology