A Voucher Artifact for Onboarding Protocols
draft-ietf-anima-rfc8366bis-36

[Ballot comment]
Thanks for addressing my DISCUSS feedback for -34.

(updated ballot for text introduced in -35)

** Section 13.5 (formerly 12.5)
  Extension name strings for IETF process (standards track,
  experimental, IRTF) documents are single words, given by the YANG
  Module Name: They do not contain dots.

-- Extension names strings for “IETF processes” are defined as “standards track, experimental, IRTF”, but “IETF processes” don’t govern the IRTF.

-- Is this text saying that this naming convention doesn’t apply to IETF stream, informational status documents?

** Section 13.5 (formerly 12.5)
  *  There are no choices in the extension names (for standards track
      extensions) 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 the provided document for clarity of purpose.  The
      stability of the reference may be of concern.

-- The earlier text says that experimental and IRTF documents there is also no choice for extension names, but here the text says the guidance only applies to standards track.

-- What would IETF stream non-standards documents get a DE review for clarity of purpose, but not an IETF stream standards track document?

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks for the discussion and addressing my concerns with the document updates.

[Ballot comment]
I support all four active DISCUSS ballots and share concerns around the document's current fitness, but I do not have additional DISCUSS worthy concerns independent of those, so I will stick with No Objection.

Minor point: Section 8.3 explains why the choice mechanism was commented out. Why is it still there at all then? I would encourage the authors to consider the utility of having that there if its use (uncommenting it) isn't recommended and if the prose within Section 8.3 to explain the lessons learned is sufficient.

[Ballot comment]
I support Ketan's DISCUSS regarding YANG validation. It would be good to get to the bottom of this, and to fix the tooling if the tooling is in fact in error.

[Ballot discuss]
I found this draft to be extremely difficult to review, as a result I have put the bulk of my comments in the comment section, not because I don't believe they are not important, but because there are many of them.  I do believe interoperability is unlikely given the current construction of this draft. 

Section 7, COSE:  It appears that cBRSKI relies on DTLS for cipher suites, which means that there is a PQ migration path in the case when signing utilizes COSE.  The ML-DSA draft for (D)TLS is nearly in the editor's queue.

Section 7, CMS:  While this draft references RFC 8366, in fact CMS has been updated to include PQ signature algorithms via RFC9882.  If a composite algorithm is more useful, then that draft is in process.  One of these should be considered. 

Section 8, para 8, 9 and 10:  I support Roman's Discuss, especially since the signatures being described in the draft are likely long lived signatures. 

Section 8, para 9:  I also support Roman's discuss wrt the fact that it appears that there is no MTI.  Given the nature of this technology, I suspect that an MTI is necessary.

[Ballot comment]
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.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-anima-rfc8366bis-34
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 8.3

Perhaps due to my lack of knowledge about YANG, but what is the expected behavior when both pinned-domain-cert and pinned-domain-pubk (or pinned-domain-pubk-sha256) are present but are inconsistent ? (e.g., the SHA256 is not correct) ?
There are comments about "Choice" surrounding this part of the YANG module, but it is probably only for human beings.

### Section 11.4

Why not a MUST in `When privacy is important, the CMS signed-data content type SHOULD be encrypted,` ? Else, provide additional guidance per IESG statement: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (even if semi obvious).

[Ballot comment]

## 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".

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I support Roman's DISCUSS regarding the post-quantum transition text
and the designated-expert guidance for the Voucher Extensions registry. I do
not repeat those points below.

I have one additional point that I would like to discuss.

Sections 8.3 and 14.1

876     import ietf-yang-types {
877       prefix yang;
878       reference
879         "RFC 9911: Common YANG Data Types";

881     }
882     import ietf-inet-types {
883       prefix ietf;
884       reference
885         "RFC 9911: Common YANG Data Types";
886     }
887     import ietf-yang-structure-ext {
888       prefix sx;
889       reference
890         "RFC 8791: YANG Data Structure Extensions";

The module imports ietf-yang-types and ietf-inet-types and explicitly
identifies RFC 9911 as their source, but RFC 9911 is absent from the reference
lists. I believe an imported YANG module requires a corresponding normative
reference? Please add RFC 9911, "Common YANG Data Types", as a normative
reference and perhaps recheck every import and include statement in both modules
against Section 14.1.

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

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].

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

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.

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].

[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     }

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.

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).

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.

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.

[Ballot discuss]
** Section 8
      Of the above, EcDSA SHOULD be supported by all implementations, until
      some quantum-safe variant is standardized.

Could this guidance be clarified?  It appears that this revised specification is publishing guidance which might not be resistant to attacks from a quantum computer. Aren’t there standardized “quantum-safe variants” of signature algorithms (e.g., ML-DSA)?  If those aren't possible to use for some reason, this risk needs to be documented in the Security Considerations section.

** Section 12.5.  BCP14 keywords should not be used in the guidance to IANA.

** Section 12.5
  The Designated Expert should determine if the work overlaps with
  existing efforts; and if so suggest merging/coordinating.  However,
  as registration is optional, the Designated Expert should not block
  any vendor registrations.

-- What are “existing efforts” – vendor and IETF efforts? 

-- Why is it appropriate for a DE to “suggest/coordinate” activity between multiple non-IETF parties (in the case of a vendor registrations) or a WG+vendor?

** Section 12.5
  *  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.

Where is the DE guidance for “non-standards track”?  All the text says is that the DE should review it.  Review it for what?

[Ballot comment]
** 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.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-anima-rfc8366bis-31. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are seven actions that we must complete. We also have a questions and comments about the second, fifth and seventh actions requested in the IANA Considerations section of this document.

First, in the ns subregistry in the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

the existing registrations for:

URI - urn:ietf:params:xml:ns:yang:ietf-voucher
and
URI - urn:ietf:params:xml:ns:yang:ietf-voucher-request

will have their references changed to [ RFC-to-be ].

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG Module will be registered as follows:

name: ietf-voucher
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-voucher
Prefix: vch
Module:
Reference: [ RFC-to-be ]

name: ietf-voucher-request
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request
Prefix: vcr
Module:
Reference: [ RFC-to-be ]

IANA Comment -> We've been asked to post new YANG modules without referencing the old modules when reference updates are needed. Could the text in Section 12.2 be changed to reflect this, removing the requests to update references and instead treating these as new registrations:

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

Third, in the application namespace of the Media Types registry located at:

the existing registration for:

Type name: application
Subtype name: voucher-cms+json

will have its reference changed to [ RFC-to-be ].

Fourth, in the SMI Security for S/MIME CMS Content Type Registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

the existing registration for:

Decimal: 40
Description: id-ct-animaJSONVoucher

will have its reference changed to [ RFC-to-be ].

Fifth, a new registry is to be created called the Voucher Extensions registry.

IANA Question -> Should this new registry be a standalone registry, or should it be in an existing registry group?

The registration procedure for the new registry is FIrst Come First Served as defined by [ RFC8126 ].

IANA Question -> Is it correct that the each entry in the new registry has an extension name, extension SID and a reference?

IANA Question -> Section 12.5 indicates that the new registry is First Come First Served, but also contains extensive instructions to Designated Experts. Is expert review the intended registration procedure instead of First Come First Served?

IANA Question -> Are there any initial registrations in the new registry?

Sixth, in the IETF YANG-SID Ranges registry in the YANG SIDs registry group located at:

https://www.iana.org/assignments/yang-sid/

the early registrations for the following two ranges will be made permanent and their reference changed to [ RFC-to-be ] as follows:

Entry Point: 2450
Size: 50
Module Name: ietf-voucher

Entry Point: 2500
Size: 50
Module Name: ietf-voucher-request

Seventh, in the IETF YANG-SID Modules registry also in the YANG SIDs registry group located at:

https://www.iana.org/assignments/yang-sid/

two new registrations will be made as follows:

YANG Module Name: ietf-voucher
YANG File: [ the pointer to the .yang file from Section 8.3 ]
SID FIle: [ a pointer to the file from Appendix B.1 ]
Size: 17
Reference: [ RFC-to-be ]

and

YANG Module Name: ietf-voucher-request
YANG File: [ the pointer to the .yang file from Section 9.2 ]
SID FIle: [ a pointer to the file from Appendix B.2 ]
Size: 24
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We also understand that the designated experts for the IETF YANG-SID Ranges registry will be providing us with the ".sid" files to be posted.

IANA Question -> When should we post these ".sid" files? Should we post them at the same time as the YANG Modules (we post YANG Modules after the the document is published as an RFC and receives an RFC number), or should we post them at upon approval of the I-D for publication as an RFC (we complete most registry actions then, after we're notified by the RFC Editor that the I-D has been approved for publication as an RFC by the IESG). Please note that the links to the respective YANG Module files in the YANG-SID registrations will be posted only upon the document's publication as an RFC, after the YANG Module files are uploaded.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-06-18):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-rfc8366bis@ietf.org, mjethanandani@gmail.com, shengjiang@bupt.edu.cn
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Voucher Artifact for Bootstrapping Protocols) to Proposed Standard


The IESG has received a request from the Autonomic Networking Integrated
Model and Approach WG (anima) to consider the following document: - 'A
Voucher Artifact for Bootstrapping Protocols'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-06-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a strategy to securely assign a candidate
  device (Pledge) to an Owner using an artifact signed, directly or
  indirectly, by the Pledge's manufacturer.  This artifact is known as
  a "Voucher".

  This document defines an artifact format as a YANG-defined JSON or
  CBOR document that has been signed using a variety of cryptographic
  systems.

  The Voucher Artifact is normally generated by the Pledge's
  manufacturer (i.e., the Manufacturer Authorized Signing Authority
  (MASA)).

  This document obsoletes RFC8366: it includes a number of desired
  extensions into the YANG module.  The Voucher Request YANG module
  defined in RFC8995 is also updated and now included in this document,
  as well as other YANG extensions needed for variants of RFC8995.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-rfc8366bis/



No IPR declarations have been submitted directly on this I-D.

Closed request for IETF Last Call review by DNSDIR with state 'Team Will not Review Document': Grossly unreasonable deadline! There's an undefined term: DNS-ID. Please resubmit to dnsdir with a sensible deadline.

In reviewing the changes made between -27 and -29, I noticed one comment from Esko, which does not seem to have been addressed. If no change is required, feel free to let me know.

# Document Shepherd Write-Up for Group Documents, template from
datatracker.ietf.org, dated 4 July 2022.

draft-ietf-anima-rfc8366bis-25 write-up


1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Strong consensus including good in-person discussions with past and present
ADs during IETF meetings.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are several pre-existing implementations of BRKSI (RFC8995) that are using
the JSON encoding of the rfc8366 voucher according to the rfc7951 yang/json
mapping rules. These where validated to interoperate and that rfc8366bis still
provides backward compatible definitions of those BRSKI vouchers.

There are two implementations of the subset of rfc8366bis required for cBRSKI
(sandelman, iot-consultancy).

There are two implementations for the subset of rfc8366bis required for BRSKI-PRM
(siemens).

We think we have a significant number of implementers overall. The document
describes a superset of features of several different BRSKI variations. This list is likely
not complete.

We currently have no RFC embedded implementation reporting, but one is planned
to be included in the cBRSKI drafts (still in IETF processing).


5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The authors think no further reviews are needed. The co-authors of all the BRSKI
variations did extensively review rfc8366bis to ensure that it will work for their
variation of BRSKI. Those BRSKI variation draft/RFCs also had significant reviews
from other parts of the IETF.

Discussions for proposing to use specific BRSKI technologies such as cBRSKI, and
in dependency rfc8366bis outside of IETF are occuring by authors (e.g.: with Thread).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were (as described above) many discussions with yang doctors occured,
and one of the yang doctors is a co-author (Qiufang Ma), no formal review
request was done yet. If necessary the authors suggest to ask Per Anderson, or
even better Rob Wilton (who seemingly was not re-added to yang doctors after
finishing his AD run).

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. According to  authors, Pyang-2.7.1 is used to create the SID list for cBRSKI
included in the draft, it passes all checks. YANG is used for Data at Rest which is
outsideof the scope of NMDA. This is unchanged since RFC8366.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Only YANG is used as a formal language (see above).

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, for me, this document is in good sharp now.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No expert issues for this OPS area doc outside the above YANG details.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Requested publication type: Standard Track.

Proper type because this is a new revision of RFC8366 which already is standard
and this version is backward compatbile, adding new extensions - without the
need for any existing or future RFC to still refer to RFC8366.

Header attributes correctly indicate standards track and obsoletion of rfc8366.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, Authors where reminded endless times through the IETF Note Well of
their responsibilities to disclose IPR to the IETF. Including every time when
uploading a new version of the draft.

There is no IPR disclosure for this document.

It was mentioned that rfc8995, which this document updates too, has a IPR
disclosure. Up to now, the owner of that IPR have not extended their IPR
disclosure to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes. This document has five authors. They all expressed their willingness to be
listed by emails.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This document is currently Nits free.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

NA.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This RFC will obsolete RFC8366. For now, the Metadata and abstract text use
word "update". The author said it would be fixed in next -026 version. It also
update RFC8995.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

From the document shepherd's review, all above has been done correctly.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Suggested Experts: Same as for the pre-existing BRSKI IANA registry tables.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents, template from
datatracker.ietf.org, dated 4 July 2022.

draft-ietf-anima-rfc8366bis-25 write-up


1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Strong consensus including good in-person discussions with past and present
ADs during IETF meetings.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are several pre-existing implementations of BRKSI (RFC8995) that are using
the JSON encoding of the rfc8366 voucher according to the rfc7951 yang/json
mapping rules. These where validated to interoperate and that rfc8366bis still
provides backward compatible definitions of those BRSKI vouchers.

There are two implementations of the subset of rfc8366bis required for cBRSKI
(sandelman, iot-consultancy).

There are two implementations for the subset of rfc8366bis required for BRSKI-PRM
(siemens).

We think we have a significant number of implementers overall. The document
describes a superset of features of several different BRSKI variations. This list is likely
not complete.

We currently have no RFC embedded implementation reporting, but one is planned
to be included in the cBRSKI drafts (still in IETF processing).


5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The authors think no further reviews are needed. The co-authors of all the BRSKI
variations did extensively review rfc8366bis to ensure that it will work for their
variation of BRSKI. Those BRSKI variation draft/RFCs also had significant reviews
from other parts of the IETF.

Discussions for proposing to use specific BRSKI technologies such as cBRSKI, and
in dependency rfc8366bis outside of IETF are occuring by authors (e.g.: with Thread).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were (as described above) many discussions with yang doctors occured,
and one of the yang doctors is a co-author (Qiufang Ma), no formal review
request was done yet. If necessary the authors suggest to ask Per Anderson, or
even better Rob Wilton (who seemingly was not re-added to yang doctors after
finishing his AD run).

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Yes. According to  authors, Pyang-2.7.1 is used to create the SID list for cBRSKI
included in the draft, it passes all checks. YANG is used for Data at Rest which is
outsideof the scope of NMDA. This is unchanged since RFC8366.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Only YANG is used as a formal language (see above).

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, for me, this document is in good sharp now.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No expert issues for this OPS area doc outside the above YANG details.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Requested publication type: Standard Track.

Proper type because this is a new revision of RFC8366 which already is standard
and this version is backward compatbile, adding new extensions - without the
need for any existing or future RFC to still refer to RFC8366.

Header attributes correctly indicate standards track and obsoletion of rfc8366.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, Authors where reminded endless times through the IETF Note Well of
their responsibilities to disclose IPR to the IETF. Including every time when
uploading a new version of the draft.

There is no IPR disclosure for this document.

It was mentioned that rfc8995, which this document updates too, has a IPR
disclosure. Up to now, the owner of that IPR have not extended their IPR
disclosure to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes. This document has five authors. They all expressed their willingness to be
listed by emails.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This document is currently Nits free.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

NA.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This RFC will obsolete RFC8366. For now, the Metadata and abstract text use
word "update". The author said it would be fixed in next -026 version. It also
update RFC8995.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

From the document shepherd's review, all above has been done correctly.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Suggested Experts: Same as for the pre-existing BRSKI IANA registry tables.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed to previous authors: Esko Dijk , Kent Watsen , Max Pritikin , Michael Richardson , Qiufang Ma , Toerless Eckert , anima-chairs@ietf.org