I am reviewing draft-ietf-anima-voucher-05 as the representative from the OPS directorate (OPS-DIR).  This draft describes the format and signing for voucher artifacts used in various bootstrapping protocols.  This document does not describe those protocols.

Overall I struggled a bit to understand this document and how to interpret some items.  In part, some of the difficulty comes from the fact that this is broken out from the bootstrapping protocols that use the voucher.  But also, there seem to be some gaps in terms of what a device _does_ with the voucher.  There was also an issue with terminology that made the first read-through a bit confusing (which I describe below). 

The biggest thing I want to call out is "processing" is expected on the device given a specific voucher?  The YANG module makes reference to what should happen relative to this processing based on the value of certain fields, but I am uncertain as to exactly what a device will do once it receives the voucher.  One case in particular that caused some confusion is around the assertion:

"The assertion is a statement from the MASA regarding how
the owner was verified.   This statement enables pledges
to support more detailed policy checks.  Pledges MUST
ensure that the assertion provided is acceptable before
processing the voucher."

How does the pledge (i.e., device) ensure the assertion is acceptable?  If this is bootstrap protocol-specific, perhaps there can be some references here to help.

In terms of revocation tests, it might be worth mentioning (from an operator perspective) that doing this may require broader internet connectivity than a bootstrapping device may typically have.  Opening up that connectivity may be problematic from a security standpoint.  There might, therefore, be some requirements or recommendations put on the bootstrapping services to make sure a device is both protected and can verify the validity of a cert.

From a terminology standpoint, the use of the word "pledge" seems odd.  The use of this word may not translate as clearly outside of the US.  Why not something like candidate?

Below are my section-by-section reviews:

Section 1:

There is a reference to a "second category" of vouchers, but this is not referenced anywhere else.  I'm not sure what the "categories" of vouchers are.  More explanation (or rephrasing) is required here.

You misspelled "programmatic" as "programatic".

===

Section 2:

You use mixed case of terminology here and throughout the document (domain vs. Domain seems to be the most egregious).  I recommend making sure that key terms are used with consistent case throughout.

MASA server is not well-defined.  You expand the acronym, but you do not really explain what a MASA server _is_.  Maybe this isn't the right document for that, but then there should be a reference to where one can really understand this element.

===

Section 5:

Typo:

"This does not direct prevent the MiTM but provides a response"

Maybe you mean, "This does not directly prevent" or "This does not prevent"

Section 6:

You have a duplicate word, "use":

A possible other use use could be as a "signed voucher request" format originating from pledge or registrar toward the MASA.

===

Section 6.1:

Is this needed?  Can you simply refer to draft-ietf-netmod-yang-tree-diagrams?

===

Section 6.3:

In the description for created-on, you state that this node is not mandatory.  However, it is defined as "mandatory true".