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](https://datatracker.ietf.org/doc/rfc8995/)] and [cBRSKI].
<minor> [RFC 8572](https://datatracker.ietf.org/doc/rfc8572/) 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](https://datatracker.ietf.org/doc/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](https://datatracker.ietf.org/doc/bcp14/) 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](https://datatracker.ietf.org/doc/rfc6020/)] [[RFC9890](https://datatracker.ietf.org/doc/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](https://datatracker.ietf.org/doc/rfc8366/)
1831 name: ietf-voucher-request
1832 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request
1833 prefix: vcr
1834 reference: [RFC 8995](https://datatracker.ietf.org/doc/rfc8995/)
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>
