Code change:
3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.

Related discussion:
text: Addressing
Issue needed.
Should we allow or forbid that eadlabel = k and eadlabel = -k correspond to different ead-values? For example, if an (eadlabel, eadvalue) is always critical: Say, eadvalue is an ACE Access Token with eadlabel = -4, always critical. Then we can either: forbid the use of eadlabel = 4 altogether, or allocate an always non-critical EAD to eadlabel = 4, say, eadvalue is "service indication" as in In case 1 we will have some "holes" in the register. One positive integer blocked for each always critical (eadlabel, eadvalue) , one negative blocked for each always non-critical (eadlabel, eadvalue), and 0 cannot be used. (It is not clear to me that there are many always non-critical, but always critical is probably common.) In case 2, we could still have the registration policy that: if an EAD can be either critical or non-critical then two eadlabel with same absolute value should be reserved for it. What is the main risk with case 2? If someone misunderstands or by accident changes sign on an always /non-/critical EAD this results most likely in an error due to wrong eadvalue (like in the example above), but potentially in an unintended EAD message. (Another registration policy could be that the eadvalues corresponding to ead_labels k and -k should have incompatible CDDL so the error is discovered ...) The EAD specification needs anyway to specify what are the processing rules and if you violate those more or less anything could happen. Comments?
BTW, we may want a term for the ordered pair (eadlabel, eadvalue). The term "EAD" or "EAD field" is referring to the message field, which may consist of multiple (eadlabel, eadvalue).
Just seems like overoptimization to me. I would prefer if we follow the model that we agreed on for C509 which is similar to what CoAP Options is using. If you think it is important to use the complete code point space I think it would be better not assign any functionality to the minus sign and register critical and non-critical idenpendently. The original proposal seems to give two different meanings to the minus sign.