If the goal is to enable interoperability, then this draft needs to be cleaned up to be clear, concise, and logical.  Currently, it appears to be a mishmash of terminology and loose specifications.  I will give some examples below where I think it is unclear, but I can't claim to be complete in my review:

Section 1, para 4:  I'm confused by this statement:  'the Pledge can then use the resulting anchor to authenticate other actors who are part of the network'.  Is this because other 'actors' hold the private key for the trust anchor?  Is it because other 'actors' have certificates that are signed by the trust anchor?   Does the Pledge hold a key and certificate certified by the trust anchor?

Section 1, para 7 and 8: These two paragraph does not flow from the previous paragraphs which are discussing trust anchors, vouchers and pledges.  Perhaps a sub section would help.

Section 1, para 9 and 10:  yet another jump.  This time, it might make sense to move these before para 7 and 8.  When a specification jumps around from topic to topic, it is difficult to see how any implementer will be able to follow - severely impacting interoperability.

Section 2, Bootstrapping and onboarding:  If bootstrapping is being deprecated, merely state that and point to the onboarding definition.  One can only hope that there is a good reason for this terminology shift.

Section 2, Imprinting:  This is a lovely idea, but how does it mesh with what was discussed in Section 1 where the terms Voucher, Pledge, and trust anchors.  Would the term 'Trust Anchor' be more suitable?

Section 2, Join Registrar:  How important is the phrase 'perhaps autonomically'?  And if it is referred to as 'just Registrar', then why not define 'Registrar'?

Section 2, Malicious Registrar:  What is the entity seeking to do, presumably to the Pledge?  

Section 2:  I'm not sure the terminology could be more confusing.  For example:  "Voucher:  a Voucher Artifact, not a Voucher Request...", while "Voucher Request:  a signed artifact...."  But while a Voucher Request is a signed artifact (does lower case make it different?), it is not a Voucher.  I don't even know what to suggest.

Section 4, Assertion Basis:  what is 'measured boot'? (I know what 'secure boot' is)

Section 4:  It is really unclear exactly how the use of nonces or time limits blocks a malicious registrar.  This is especially true if the nonces are transmitted in the clear.

Section 5: Where is the list of changes?  

Section 5.1:  What is the purpose of this section?  A clear and concise list of changes would be more useful.

Section 8, EcDSA:  https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list suggests that this should be ECDSA (which is also the only way I've ever seen it).

Section 9.1:  'manufacturer-private?'.  Does this imply the manufacturer's private key?  Surely this isn't sent to anyone.

Section 10.1, para 2:  'Revocation artifact'?  Like an OCSP response showing that the current key/cert pair is still valid?  OCSP is specified in RFC 6960.

Section 10.1, para 3:  Updating a short-lived certificate requires the same care as the initial certification.  It is more than merely 'updates the Voucher's validity period'.  One needs to ensure that the entity that holds the private key still possesses it, and hasn't disclosed it. 

Section 11.1, para 2:  Devices with no understanding of time cannot possibly verify that the 'expires-on' field has not yet passed.  

Section 11.2:  Why not MUST?  What are the circumstances in which is it ok to not store that private key in an HSM?

Section 11.4:  For sensitive data fields which are distributed, I would expect these structures to be encrypted as well as signed.  Nonces and other private values should not be distributed in the clear (or merely signed).  I would have preferred to see the carefully constructed paragraph which is normally standard in Yang specifications.

## COMMENTS (non-blocking)

### YANG errors ?

The data tracker status page indicates 4 errors and 3 warnings, the shepherd's write-up is silent about these errors.

### Other DISCUSS

I second Roman Danyliw's DISCUSS about post-quantum in section 8 (and also the use of SHOULD without any additional guidance) and use of BCP14 in the IANA considerations.

### Short and long lifetime

Section 10.1 and others mention short lifetime but without giving any guidance to the readers/implementers about the duration of "short lifetime".

Please find below some comments on this document inline in the idnits output
of v34. Please look for the <EoRv34> tag at the end to ensure that you are
seeing the complete review.

<major> Sections 8.3 and 9.2

The current Datatracker YANG validation result for the exact v34 modules is not
clean. Can this be cross-checked and fixed?

200	   Some Onboarding protocols using the Voucher Artifact defined in this
201	   document include: [ZERO-TOUCH], [SECUREJOIN], [RFC8995] and [cBRSKI].

<minor> RFC 8572 is cited here only as an example of another Onboarding
protocol. It does not appear necessary to implement or use this specification.
Am I correct? If so, please move [ZERO-TOUCH] from the normative to the informative 
references.

549	   It is not possible for the Pledge or the Registrar to know which
550	   situation applies.  And because one the above situations may apply,
551	   or may occur in the future, there needs to be a contingency to allow
552	   uniquely identifying a Pledge regardless of the current or future

<nit> s/because one the above situations/because one of the above situations/

564	   For the RVR, Section 6.1 now normatively requires that the 'idevid-
565	   issuer' Attribute must be included.

567	   For the Voucher, Section 8.3 normatively requires ("must") that the
568	   'idevid-issuer' Attribute must be included by a MASA in case the MASA
569	   issues a Voucher with a serial number that is known to be not unique
570	   within the scope of all the serial numbers represented by the MASA.
571	   If this rule does not apply, the MASA SHOULD NOT include the 'idevid-
572	   issuer' Attribute in order to achieve a smaller Voucher size.

<minor> These sentences describe their requirements as normative while using
lowercase "must". Suggest to either use MUST where these sentences themselves
state requirements, or rewrite them as descriptive cross-references to the
requirements in Sections 6.1 and 8.3. I leave the final choice to the authors.

598	6.4.  Errata closed

600	   The above updates to [RFC8995] addresses errata [eid7263].

<minor> [eid7263] records the provenance of a correction that has already been
incorporated into the normative text. It does not appear necessary to
implement or use this specification. Please move it from the normative to the
informative references.

938	     revision 2025-12-18 {
939	       description
940	         "Updates and additions described by RFC XXXX";
941	       reference
942	         "RFC XXXX: A Voucher Profile for Bootstrapping Protocols";
943	     }

<nit> The document title is "A Voucher Artifact for Bootstrapping Protocols".
Perhaps use that title in the revision reference?

1739	   There are three things to defend against this: 1) devices are
1740	   required to verify that the 'expires-on' Attribute has not yet
1741	   passed, 2) devices without access to time can use nonces to get
1742	   ephemeral Vouchers, and 3) Vouchers without expiration times may be
1743	   used, which will appear in the audit log, informing the security
1744	   decision.

1746	   This document defines a Voucher format that contains time values for
1747	   expirations, which require an accurate clock in order to be processed
1748	   correctly.  Vendors planning on issuing Vouchers with expiration
1749	   values must ensure that devices have an accurate clock when shipped
1750	   from manufacturing facilities and take steps to prevent clock
1751	   tampering.  If it is not possible to ensure clock accuracy, then
1752	   Vouchers with time values for expirations should not be issued.

<minor> Please review the lowercase "must" and "should" in this security-
relevant text. Use the uppercase BCP 14 keywords where these sentences
establish requirements; otherwise rewrite them declaratively. I leave the
individual choices to the authors.

1756	   Pursuant to the recommendation made in Section 6.1 for the MASA to be
1757	   deployed as an online Voucher signing service, it is RECOMMENDED that
1758	   the MASA's private key used for signing Vouchers is protected by a
1759	   hardware security module (HSM).

<minor> Is section 6.1 the correct reference here? I was not able to find the
right one and if no section contains that recommendation, either add it to an 
appropriate specification or operational section, or remove the introductory
cross-reference and state things inline.

1822	   IANA is requested to register the following YANG module in the "YANG
1823	   Module Names" registry [RFC6020] [RFC9890] within the "YANG
1824	   Parameters" registry group.

1826	      name:  ietf-voucher
1827	      namespace:  urn:ietf:params:xml:ns:yang:ietf-voucher
1828	      prefix:  vch
1829	      reference:  RFC 8366

1831	      name:  ietf-voucher-request
1832	      namespace:  urn:ietf:params:xml:ns:yang:ietf-voucher-request
1833	      prefix:  vcr
1834	      reference:  RFC 8995

1836	   (Please note the change to the "prefix" field)

1840	   IANA is requested to register the media type: application/voucher-
1841	   cms+json, and this registration should be updated to point to this
1842	   document.

1885	   IANA is requested to register the OID 1.2.840.113549.1.9.16.1.40,
1886	   'id-ct-animaJSONVoucher'.  This registration should be updated to
1887	   point to this document.

<major> These are existing registrations, but the instructions alternate
between asking IANA to register them and asking IANA to update them. Section
12.2 also retains the old RFC references despite this document replacing or
updating the defining specifications.

Please rewrite each subsection as a precise update action. For each YANG
module registration, identify exactly which fields are updated, including the
new RFC reference and the prefix change, while preserving any registration
history required by the registry. Ask IANA to update the existing
application/voucher-cms+json and id-ct-animaJSONVoucher registrations rather
than creating new registrations. It would also help to keep one subsection per
distinct IANA action and clearly distinguish new entries from modifications of
existing entries.

<EoRv34>

** Section 8  
    When EcDSA is supported, curves secp256r1 and secp384r1 SHOULD be	
    supported.  When EdDSA is supported, curves Ed25519 and Ed448 SHOULD	
    be supported.  When RSA is supported by an implementation, it SHOULD	
    support key lengths between 2048 and 4096 bits.	

-- If all of the normative requirement for the curves are defined as a “SHOULD”, it appears that there are no MTI.  Is that desireable/intentional?

-- Under what circumstances would it be acceptable to use an RSA key length of <2048 bits? 

** Section 12.5
  Future work may allow for PEN based allocations.

Is this text needed?  No action can be taken on it.

** Section 12.5
   Extension name strings for standards track documents are single
   words, given by the YANG Module Name.  They do not contain dots.
   For vendor proprietary extensions, the string SHOULD be made unique
   by putting the extension name in the form a fully-qualified domain
   name (FQDN) [RFC3696], such as "fuubar.example.com"

What about documents which are not on the standards track (e.g., experimental on the IETF stream, and ISE or IRTF document)

** Section 12.5
   For vendor proprietary extensions, the string SHOULD be made unique
   by putting the extension name in the form a fully-qualified domain
   name (FQDN) [RFC3696], such as "fuubar.example.com"

When is it acceptable for a non-unique name to be used?  This text allows for duplicate names to be registered?

** Section 12.5
   Designated Experts should review for standards track documents for
   clarity, but the choices are tied to WG and IESG processes:

   *  There are no choices in the extension names (which is always the
      YANG module name), or SID value (which is from another IANA
      process).

   *  For non-standards track extensions, the Designated Expert should
      review whatever document is provided, if any.  The stability of
      the reference may be of concern.

-- Editorial.  Is there an editorial issue in the first sentence? s/should review for/should review/?

-- What does it mean that the “choices are tied to WG and IESG processes?”  What processes?

-- Editorial.  Why is guidance about non-standards track extensions part of guidance (a sub-bullet) of guidance for standards track.