Draft: draft-ietf-lake-edhoc

Commentary: I strongly think that all 10 EDHOC - KDF should be in the same table The text about maclengthx need to use the defined term hash_length 
 I made one commit for review .
Paragraph (version A):
EDHOC is designed to encrypt and integrity protect as much
information as possible.  Symmetric keys and random material derived
using EDHOC_KDF are derived with as much previous information as
possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as
compact and lightweight as possible, in terms of message sizes,
processing, and the ability to reuse already existing CBOR, COSE, and
CoAP libraries.  Like in (D)TLS, authentication is the responsibility
of the application.  EDHOC identifies (and optionally transports)
authentication credentials, and provides proof-of-possession of the
private authentication key.
Paragraph (version B):
EDHOC is designed to encrypt and integrity protect as much
information as possible.  Symmetric keys and random material used in
EDHOC are derived using EDHOC_KDF with as much previous information
as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be
as compact and lightweight as possible, in terms of message sizes,
processing, and the ability to reuse already existing CBOR, COSE, and
CoAP libraries.  Like in (D)TLS, authentication is the responsibility
of the application.  EDHOC identifies (and optionally transports)
authentication credentials, and provides proof-of-possession of the
private authentication key.
Paragraph (version A):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output session key of a successful EDHOC exchange.
Paragraph (version A):
Keys for applications are derived using EDHOC_Exporter from
PRK_exporter (see exporter) which in turn is derived from PRK_out.
For the purpose of generating application keys, it is sufficient to
store PRK_out or PRK_exporter.  (Note that the word "store" used here
does not imply that the application has access to the plaintext
PRK_out since that may be reserved for code within a Trusted
Execution Environment, see impl-cons).
Paragraph (version A):
This section defines EDHOC_Exporter in terms of EDHOC_KDF and
PRK_out.  A key update function is defined in keyupdate.
Paragraph (version B):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is
the output session key of a successful EDHOC exchange.
Paragraph (version B):
Keys for applications are derived using EDHOC_Exporter (see exporter)
from PRK_exporter, which in turn is derived from PRK_out as shown in
fig-edhoc-kdf.  For the purpose of generating application keys, it is
sufficient to store PRK_out or PRK_exporter.  (Note that the word
"store" used here does not imply that the application has access to
the plaintext PRK_out since that may be reserved for code within a
Trusted Execution Environment, see impl-cons).
Paragraph (version B):
This section defines EDHOC_Exporter in terms of EDHOC_KDF and
PRK_exporter.  A key update function is defined in keyupdate.
Paragraph (version A):
where hash_length denotes the output size in bytes of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version A):
If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC
length of the selected cipher suite.  If the Responder
authenticates with a signature key (method equals 0 or 2), then
mac_length_2 is equal to the output size of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version B):
If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC
length of the selected cipher suite.  If the Responder
authenticates with a signature key (method equals 0 or 2), then
mac_length_2 is equal to hash_length.
Paragraph (version A):
If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC
length of the selected cipher suite.  If the Initiator
authenticates with a signature key (method equals 0 or 1), then
mac_length_3 is equal to the output size of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version B):
If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC
length of the selected cipher suite.  If the Initiator
authenticates with a signature key (method equals 0 or 1), then
mac_length_3 is equal to hash_length.