Reviewer: Henk Birkholz Review result: Not Ready I am the assigned IoT Directorate reviewer for I-D.ietf-anima-constrained-voucher-12 as part of the IoT Directorate's effort to provide early feedback to IoT-related IETF documents before being processed by the IESG. Document authors, document editors, WG chairs and Area Directors should treat these comments just like any other WG comments. This early review focuses on the body of the memo and does not extend to the examples in the appendices. Summary: The document proposes a solution that introduces CBOR-based voucher and EST-CoAPS based enrollment as a more concise variant of JSON-based vouchers and EST over HTTPS based enrollment as defined by RFC8995 and RFC8366. The general concept makes a lot of sense as CBOR's (and in consequence COSE's) footprint on message size, processing code size, and computation resources combined is significantly lower in comparison with JSON (and CMS), ultimately enabling future interoperability with a host of constrained node types. The document is work in progress as indicated by editor's notes and various TBD placeholders. (0) Title The title implies that this document defines a message or document called 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The first sentence contradicts this by saying 'This document defines a protocol'. This "IETF'ler Human" also suspects that "Voucher Artifacts" are kind of redundant, but that was okay in RFC8366 so that seems to be okay here. (1) Abstract The abstract requires more (concise!) context and outline of the general problem so that context-specific terms used can be easily understood, e.g., 'Pledge' or its relationship to 'owner'. Imagine the abstract being the only thing visible in a document indexing and management system and phrase it as such. The "new" CoAP protocol defined seems to be a complement to an HTTPS protocol, which the reader has to guess is defined either by RFC8366 or BRSKI (this is cleared up early in the Intro). Why is it not CoAPS, if its complement is HTTPS? Ultimately, you shall not use references in an abstract and that is the root cause for this need for guessing here, I think. (2) Introduction OSCORE and EDHOC are suddenly used and not introduced. Terms, such as 'Pledge' or 'Registrar' could be better introduced or it should be very clearly stated that this memo cannot be used without a clear understanding of other documents (and which documents that exactly are and why). It is not very clear to the reader why YANG and SID are suddenly appearing here (which again becomes pretty obvious when you read other documents). In general, the Intro requires more context. (3) Overview of Protocol It is not immediately clear what 'proximity' means here (the term is not listed in the Terminology section). A quick recap of roles and interactions would not hurt, I think, but that can also be addressed by adding more contextual text to the Intro. "Most Pledges using these constrained": maybe just remove the "these" - it made me read it as a back-reference to time-based vouchers. The term "pinned" used here could benefit a from a tad bit more expositional text - it is a term relevant to a lot of security aspects in this memo and deserves a proper introduction. (4) Discovery, URIs and Content Formats Maybe an example of EST and BRSKI URIs helps the reader to see the difference/optimization more easily? The terms URI and URL or both used in this section. Are they used dedicatedly with their distinct meanings or are they used interchangeably? Sometimes the term 'end point' is also spelled 'end-point'. Why is there a fall-back (as MAY) to Content-Format 50 for the shorter URLs? (5) Extensions to BRSKI 'CoRE Link Format parsing' is suddenly used and it is not clear here in the context why avoiding that is useful. I am not sure that 'reconnect' is the appropriate term to use when writing about resources available via a single UDP port. (6) Extensions to EST-coaps The example '/sen' for simple enrollment is used here, but not really introduced in the document. Is that intentionally so? (7) Pledge Extensions '/att' is introduced here and it might not be obvious to a reader where that comes from and what it exactly represents. Maybe a small example for "it MUST use the Subject Distinguished Name fields from its IDevID unmodified." would help here? Is '/crts' the short-name for '/cacerts'? So - in general, maybe there should be a complete list of short-names used or are these intentionally just used as examples? (8) Registrar Extensions "for operational or security reasons" - that could be a topic for the TBD in the Security Considerations. (9) BRSKI-MASA Protocol Some of the consideration about "CoAPS for the BRSKI MASA is deemed unrealistic" can probably also fuel the Security Considerations. (10) Registrar Identity Selection and Encoding 'which participate' -> 'that participate' (11) MASA Pinning Policy Maybe explicitly highlight that in the case of the nonce-less vouchers, the makeup of the x5bag provides the knobs and dials to exactly influence which certificate will be pinned. That is only expressed implicitly, I think, or I did not get the meaning of the text properly. (12) Pinning of Raw Public Keys "However, if the Pledge is known to also support RPK pinning and the MASA intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin the RPK (RPK3 in Figure 2) of the Registrar instead of the Registrar's End-Entity certificate to save space in the voucher.": why is that not a MUST? What are the consequences, if that is not done as highlighted? Viele Grüße, Henk