RATS Conceptual Messages Wrapper (CMW)
draft-ietf-rats-msg-wrap-23

[Ballot comment]
Hi Thomas, all,

Thank you for the discussion and for the changes made in -22 [1]. These addresses the comments raised in my previous ballot [2].

One very minor comment about the newly added figures: Other than that these are not called out in the main text, it is obvious that RP shown there is about Relying Party. You may consider s/Relying Party/Relying Party (RP) + adding captions for these two figures. Obviously, this is the kind of changes that can wait for AUTH48.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-rats-msg-wrap-21&url2=draft-ietf-rats-msg-wrap-22&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/rats/kPi3XwQuOqvKln7NK1I_fdPdqts/

[Ballot comment]
# Review of draft-ietf-rats-msg-wrap-21

CC @MikeBishop

## Comments

### Section 1, paragraph 3
```
    *  In a "background check" topology, Evidence (e.g., EAT [RFC9711])
        first flows from the Attester to the Relying Party and then from
        the Relying Party to the Verifier, each leg following a separate
        protocol path.

    *  In a "passport" topology, an attestation result payload (e.g.,
        Attestation Results for Secure Interactions (AR4SI)
        [I-D.ietf-rats-ar4si]) is initially sent from the Verifier to the
        Attester, and later, via a different channel, from the Attester to
        the Relying Party.
```
An informative reference to the definition of these topologies would be nice.

### Section 5, paragraph 0

This can probably be removed, since IANA will have done so before this
draft is published. Alternatively, replace with a pointer to IANA Considerations.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 3.1, paragraph 8
```
in Section 8 of [RFC9334]. Note that that an Appraisal Policy may refer to
                                ^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.4, paragraph 5
```
chars = ALPHA / DIGIT / "!" / "#" /"$" / "&" / "-" / "^" / "_" restricted-na
                                  ^
```
Missing space before "

#### Section 6, paragraph 16
```
ntial Computing Consortium. The organisation hosts two libraries which allow
                                ^^^^^^^^^^^^
```
Do not mix variants of the same word ("organisation" and "organization") within
a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
Hi Henk, Ned, Thomas, Hannes, and Dionna,

Thank you for the effort put into this specification.

I trust the CDDL and ASN modules were validated.

The document is well-written. Please find below some few DISCUSS points, mainly about references.

# RFC 9334 is normative

The concepts manipulated in this draft can’t be understood without RFC9334. This is actually ACKed in Section 2.


# DER Encoding

CURRENT:
  The DER-encoded CMW is the value of the OCTET STRING for the
  extnValue field of the extension.

Missing normative reference for DER. Maybe X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)?

# Normative References, again

CURRENT:
  This section provides an ASN.1 module [X.680] for the CMW extension,
  following the conventions established in [RFC5912] and [RFC6268].

I guess both 5912 and 6269 should be listed as normative.

[Ballot discuss]
Hi Henk, Ned, Thomas, Hannes, and Dionna,

Thank you for the effort put into this specification.

I trust the CDDL and ASN modules were validated.

The document is well-written. Please find below some few DISCUSS points, mainly about references.

# RFC 9334 is normative

## The concepts manipulated in this draft can’t be understood without RFC9334. This is actually ACKed in Section 2.

## Note that this will be a downref, though. Per RFC3967, I’m afraid that we fall under the following:

  For Standards Track or BCP documents requiring normative reference to
  documents of lower maturity, the normal IETF Last Call procedure will
  be issued, with the need for the downward reference explicitly
  documented in the Last Call itself. 

# DER Encoding

CURRENT:
  The DER-encoded CMW is the value of the OCTET STRING for the
  extnValue field of the extension.

Missing normative reference for DER. Maybe X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)?

# Normative References, again

CURRENT:
  This section provides an ASN.1 module [X.680] for the CMW extension,
  following the conventions established in [RFC5912] and [RFC6268].

I guess both 5912 and 6269 should be listed as normative.

[Ballot comment]
# JSON/CBOR encoding and Mapping

As both encoding are specifically provided in the spec, are there any deviations/implications if an implementation decide to follow the rules such as in rfc8949#section-3.4.5.2 for mapping the two?

Maybe worth to add a note?

# To ensure extensibility with interop, I guess “can add” language should be better strengthened (e.g., “is recommended to add” or the like)

CURRENT:
  Future specifications that extend the RATS Conceptual Messages set
  can add new values to the cm-type using the process defined in
  Section 10.4.

# Recursion Limit

CURRENT:
  Since the Collection CMW is recursive (a Collection CMW is itself a
  CMW), implementations MAY limit the allowed depth of nesting.

Can that be controlled? Can we ask an implem to expose the nesting depth it supports or it actually imposes?

# Further highlight this is an example

OLD:
  func CMWTypeDemux(b []byte) CMWType {

NEW:
  func example-CMWTypeDemux(b []byte) CMWType {

#  These two MUSTs are redundant

CURRENT:
  The CMW extension MUST have the following syntax:

  CMW ::= CHOICE {
      json UTF8String,
      cbor OCTET STRING
  }

  The CMW MUST include the serialized CMW object in either JSON or CBOR
  format, utilizing the appropriate CHOICE entry.

# Unfolding

CURRENT:
  with the following wire representation:

  =============== NOTE: '\' line wrapping per RFC 8792 ================


Please add 8792 to the list of references as this is needed to unfold the example.

# Nits

## Expand RATS in the title.

## Please help readers to find where to locate for Passport and Background-check models: Pointing to Section 5.1 and 5.2 of 9334 in the text would be helpful.

## Section 4.2

OLD:
  The protected header MUST include the signature algorithm identifier.
  The protected header MUST include the content type application/
  cmw+json. 

NEW:
  The protected header MUST include the signature algorithm identifier and
  the content type application/cmw+json. 

Cheers,
Med

[Ballot comment]
"Abstract", paragraph 0
> Abstract

I will note that the Shepherd Report called for an IOTDIR review to be done on the document. An early review was done on -04 version of the docuement, which put the state as "Almost ready". We are at version -21 now. A response from the authors indicates a follow-up was needed, but none can be seen in the mailing list.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[draft-ftbs-rats-msg-wrap].


-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.1, paragraph 8
>  in Section 8 of [RFC9334]. Note that that an Appraisal Policy may refer to
>                                  ^^^^^^^^^
Possible typo: you repeated a word.

Section 6, paragraph 16
> ntial Computing Consortium. The organisation hosts two libraries which allow
>                                ^^^^^^^^^^^^
Do not mix variants of the same word ("organisation" and "organization") within
a single text.

Section 11.1, paragraph 21
> e list of currently open issues for this documents can be found at https://gi
>                                    ^^^^
The singular determiner "this" may not agree with the plural noun "documents".
Did you mean "these"?

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-rats-msg-wrap-21
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rats-msg-wrap-21.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### +jws

```
1152   Name:  JSON Web Signature (JWS)
1153   +suffix:  +jws
1154   References:  [RFC7515]
1155   Encoding Considerations:  binary; values are represented as a JSON
1156       Object or as a series of base64url-encoded values each separated
1157       from the next by a single period ('.') character.
```

Given that SD-JWT (https://datatracker.ietf.org/doc/rfc9901/) now exists, do you want to include support for "~" ?

Note, that without doing so, you could have json encoded sd-jwt values, that cannot be converted to compact serialization.

You already have this issue with JSON encoded JWS that cannot be converted to compact, when the "header" parameter is required.

[Ballot comment]

## Comments

### Which JWS Serialization?

```
560   A JSON CMW can be signed using JSON Web Signature (JWS) [RFC7515].  A
561   signed-json-cmw is a JWS object with the following layout:

563   signed-json-cmw = {
564     "protected": text .b64u (text .json signed-json-cmw-protected-hdr)
565     ? "header": text .b64u (text .json signed-json-cmw-unprotected-hdr)
566     "payload": text .b64u (text .json json-cmw)
567     "signature": text .b64u bytes
568   }
```

https://datatracker.ietf.org/doc/html/rfc7515#section-7.2.1

Implication is that multiple signatures are not supported, and that some important information might be in "header" which cannot be protected by the signature.

... You cannot use "header" in compact serialization.

it would be clearer to provide CDDL for the exact serializations that are supported, for example:

```
general-jws-json / flattened-jws-json / compact-jws / compact-sd-jwt
```


## Nits

### Use before definition

```
544   cose.label = int / text
545   cose.values = any
```

In CDDL where productions like this are used, I always prefer to read them before their usage... So I don't have to backtrack to understand what has just been said.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-rats-msg-wrap-21
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Ionuț Mihalcea for the shepherd's *very* detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

Who is the `we` ? The authors ? The WG ? The IETF ? Let's avoid the use of ambiguous "we" (possibly also in other places).

### Section 1

Some graphics with all the parties and messages will make the text easier to read by non-RATS readers, pretty much like firgure 6 (even with SVG!) in appendix A.

### Section 3.1

May I assume that CBOR encoding can discreminate between an integer and a string ? This is about the "type" member.

s/ are registered at the time of writing,/ are registered *in this document*,/

### Section 3.1.1

s/The cm-type currently has five allowed values/The cm-type as defined by this document has five allowed values/

### Section 4.4.2

Please expand DICE at first use.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Ionuț Mihalcea for the shepherd's *very* detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

Who is the `we` ? The authors ? The WG ? The IETF ? Let's avoid the use of ambiguous "we" (possibly also in other places).

### Section 1

Some graphics with all the parties and messages will make the text easier to read by non-RATS readers, pretty much like firgure 6 (even with SVG!) in appendix A.

### Section 3.1

May I assume that CBOR encoding can discreminate between an integer and a string ? This is about the "type" member.

s/ are registered at the time of writing,/ are registered *in this document*,/

### Section 3.1.1

s/The cm-type currently has five allowed values/The cm-type as defined by this document has five allowed values/

### Section 4.4.2

Please expand DICE at first use.

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-rats-msg-wrap-18. If any part of this review is inaccurate, please let us know.

IANA has a question about the fourth action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are nine actions which we must complete.

First, in the CBOR Web Token (CWT) Claims registry located at:

https://www.iana.org/assignments/cwt/

a single new web token claim will be registered as follows:

Claim Name: cmw
Claim Description: A RATS Conceptual Message Wrapper
JWT Claim Name: cmw
Claim Key: [ TBD-at-Registration ]
Claim Value Type(s): CBOR map, CBOR array, or CBOR tag
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 3.1, Section 3.3 and Section 3.2 ]

Second, in the JSON Web Token Claims registry located at:

https://www.iana.org/assignments/jwt/

a single new registration will be made as follows:

Claim Name: cmw
Claim Description: A RATS Conceptual Message Wrapper
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 3.1 and Section 3.3 ]

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

Third, in the Structured Syntax Suffixes registry located at:

https://www.iana.org/assignments/media-type-structured-suffix/

a single new registration will be made as follows:

Name: JSON Web Signature (JWS)
+suffix: +jws
References: [RFC7515]
Encoding Considerations: 8bit; values are represented as a JSON Object or as a series of base64url-encoded values each separated from the next by a single period ('.') character.
Interoperability Considerations:
Fragment Identifier Considerations:
Security Considerations: [RFC7515; Section 10]
Contact: RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)
Author/Change Controller: IETF

As this also 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."

Fourth, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

a single new registration will be made as follows:

CBOR Tag: [ TBD-at-Registration ]
Data Item: CBOR map, CBOR array, CBOR tag
Semantics: RATS Conceptual Message Wrapper
Reference: [ RFC-to-be; Section 3.1, Section 3.2 and Section 3.3 ]

IANA Question --> What range of the CBOR Tags registry should this registration come from? The answer to this question determines whether expert review is required. IANA notes that all registration requests in the CBOR Tags registry are required to include the template from [RFC8949].

Fifth, a new registry is to be created called the RATS Conceptual Message Wrapper (CMW) Indicators registry. The new registry will be located in the Remote Attestation Procedures (RATS) registry group located at:

https://www.iana.org/assignments/rats/

The new registry will be managed via Expert Review as defined by [RFC8126]. There are initial registrations in the new registry as follows:

Indicator Value Conceptual Message Name Reference
---------------+---------------------------+-----------
0 Reference Values [ RFC-to-be ]
1 Endorsements [ RFC-to-be ]
2 Evidence [ RFC-to-be ]
3 Attestation Results [ RFC-to-be ]
4 Appraisal Policy [ RFC-to-be ]

IANA understands that the provisional CMW indicators registry located at:

https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/blob/main/provisional/cmw-indicators-registry.md

would be removed upon publication of this document and that registrations there are to be added to this document.

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

https://www.iana.org/assignments/media-types/

four new media types are to be registered as follows:

Name: cmw+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 3.1, Section 3.2 and Section 3.3 ]

Name: cmw+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 3.1 and Section 3.3 ]

Name: cmw+cose
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 4.1 ]

Name: cmw+jws
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 4.2 ]

Seventh, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

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

four, new identifiers will be registered in the 256 - 9999 range as follows:

Content Type:
Content Coding:
Media Type: [ application/cmw+cbor ]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content Type: application/cmw+json
Content Coding:
Media Type: [ application/cmw+json ]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content Type: application/cmw+cose
Content Coding:
Media Type: [ application/cmw+cose ]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content Type: application/cmw+jws
Content Coding:
Media Type: [ application/cmw+jws ]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Eighth, in the SMI Security for PKIX Certificate Extension in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

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

the early registration for:

Decimal: 35
Description: id-pe-cmw

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

Ninth, in the SMI Security for PKIX Module Identifier registry also in in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

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

a single new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-cmw-extn
Reference: [ RFC-to-be; Section 4.4.1 ]

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 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 2025-10-13):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-rats-msg-wrap@ietf.org, ionut.mihalcea@arm.com, rats-chairs@ietf.org, rats@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RATS Conceptual Messages Wrapper (CMW)) to Proposed Standard


The IESG has received a request from the Remote ATtestation ProcedureS WG
(rats) to consider the following document: - 'RATS Conceptual Messages
Wrapper (CMW)'
  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 2025-10-13. 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


  The Conceptual Messages introduced by the RATS Architecture (RFC9334)
  are protocol-agnostic data units that are conveyed between RATS roles
  during remote attestation procedures.  Conceptual Messages describe
  the meaning and function of such data units within RATS data flows
  without specifying a wire format, encoding, transport mechanism, or
  processing details.  The initial set of Conceptual Messages is
  defined in Section 8 of RFC9334 and includes Evidence, Attestation
  Results, Endorsements, Reference Values, and Appraisal Policies.

  This document introduces the Conceptual Message Wrapper (CMW) that
  provides a common structure to encapsulate these messages.  It
  defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and
  CBOR Web Token (CWT) claims, and an X.509 extension.

  This allows CMWs to be used in CBOR-based protocols, web APIs using
  JWTs and CWTs, and PKIX artifacts like X.509 certificates.
  Additionally, the draft defines a media type and a CoAP content
  format to transport CMWs over protocols like HTTP, MIME, and CoAP.

  The goal is to improve the interoperability and flexibility of remote
  attestation protocols.  By introducing a shared message format like
  the CMW, we can consistently support different attestation message
  types, evolve message serialization formats without breaking
  compatibility, and avoid having to redefine how messages are handled
  in each protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/



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

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Some notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

* Adjusting the precise wording and content for the Security Considerations section, particularly when applied to the use of Collection CMWs for modelling composite attesters. Both the PR ([security-cons-revamp]) and the reported issue it stemmed from ([sec-channel-insufficient]) produced lengthy discussions that ended in rough consensus.

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/
[security-cons-revamp] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/226
[sec-channel-insufficient] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/222

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists two existing implementation: a Go one [Veraison-Go] and a Rust one [Veraison-Rust] which cover all the features in the draft and are currently alpha-status.

[Veraison-Go] https://github.com/veraison/cmw
[Veraison-Rust] https://github.com/veraison/rust-cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the Security Directorate. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Since the response to the review was not ack'ed and the draft has progressed considerably, it would be beneficial for the IoT Directorate to provide another review.

Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and all authors have answered.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Some notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

* Adjusting the precise wording and content for the Security Considerations section, particularly when applied to the use of Collection CMWs for modelling composite attesters. Both the PR ([security-cons-revamp]) and the reported issue it stemmed from ([sec-channel-insufficient]) produced lengthy discussions that ended in rough consensus.

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/
[security-cons-revamp] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/226
[sec-channel-insufficient] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/222

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists two existing implementation: a Go one [Veraison-Go] and a Rust one [Veraison-Rust] which cover all the features in the draft and are currently alpha-status.

[Veraison-Go] https://github.com/veraison/cmw
[Veraison-Rust] https://github.com/veraison/rust-cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the Security Directorate. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Since the response to the review was not ack'ed and the draft has progressed considerably, it would be beneficial for the IoT Directorate to provide another review.

Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and all authors have answered.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Some notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

* Adjusting the precise wording and content for the Security Considerations section, particularly when applied to the use of Collection CMWs for modelling composite attesters. Both the PR ([security-cons-revamp]) and the reported issue it stemmed from ([sec-channel-insufficient]) produced lengthy discussions that ended in rough consensus.

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/
[security-cons-revamp] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/226
[sec-channel-insufficient] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/222

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists two existing implementation: a Go one [Veraison-Go] and a Rust one [Veraison-Rust] which cover all the features in the draft and are currently alpha-status.

[Veraison-Go] https://github.com/veraison/cmw
[Veraison-Rust] https://github.com/veraison/rust-cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the Security Directorate. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Since the response to the review was not ack'ed and the draft has progressed considerably, it would be beneficial for the IoT Directorate to provide another review.

Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

Document went through WG last call successfully and early IoT directorate review transpired and updates have been made. Updates are awaiting approval and should be smooth, so we will move the document to IETF last call.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Some notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

* Adjusting the precise wording and content for the Security Considerations section, particularly when applied to the use of Collection CMWs for modelling composite attesters. Both the PR ([security-cons-revamp]) and the reported issue it stemmed from ([sec-channel-insufficient]) produced lengthy discussions that ended in rough consensus.

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/
[security-cons-revamp] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/226
[sec-channel-insufficient] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/222

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists two existing implementation: a Go one [Veraison-Go] and a Rust one [Veraison-Rust] which cover all the features in the draft and are currently alpha-status.

[Veraison-Go] https://github.com/veraison/cmw
[Veraison-Rust] https://github.com/veraison/rust-cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Some notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

* Adjusting the precise wording and content for the Security Considerations section, particularly when applied to the use of Collection CMWs for modelling composite attesters. Both the PR ([security-cons-revamp]) and the reported issue it stemmed from ([sec-channel-insufficient]) produced lengthy discussions that ended in rough consensus.

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/
[security-cons-revamp] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/226
[sec-channel-insufficient] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/222

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Two notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check]. ASN.1 extension request has been verified by IANA Designated Expert [ASN1-request].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL]. CDDL is validated on the draft repo CI (part of the `build` job in [CDDL-CI]), and the standalone module is published alongside the draft version it belongs to (e.g., [CDDL-module]).

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ASN1-request] https://mailarchive.ietf.org/arch/msg/rats/GfpO6b1ZYVUcS057onps84BSC-4/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126
[CDDL-CI] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/actions/workflows/release-cddl.yml
[CDDL-module] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/releases/tag/cddl-draft-ietf-rats-msg-wrap-14

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Two notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL].

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.

No designated expert is suggested.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.

Reviews and comments were received from many WG members, coming from many backgrounds (e.g., IoT, confidential computing, PKIX) through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. This feedback has brought improvements to the security and privacy considerations, the design and semantics of newly proposed data structures, accuracy and correctness of sections written in formal languages (e.g., CDDL), alignment with other dependent drafts, and so on.

There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Two notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; (rough) consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

Private feedback has also indicated worries regarding the length and complexity of (using) the draft, particularly for high-level users. Document editors have instead stressed the flexibility of the design, required towards enabling a type system for RATS, and the simplicity of the existing CMW library (see question 4).

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly [ASN1-check].

The CDDL and ABNF included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL].

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders has been sent and acknowledged by all authors [IPR-Q]. No disclosures have been filed yet.

[IPR-Q] https://mailarchive.ietf.org/arch/msg/rats/wKBgthFLhZ6RKzpIzm6b5HN2zSM/

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.
No suggestion for designated expert.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.
Reviews and comments were received from many WG members through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Two notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only

* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly.

The CDDL included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL].

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders will be issued and confirmed following WGLC. No disclosures have been filed yet.

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.
No suggestion for designated expert.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.
Reviews and comments were received from many WG members through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. There is strong consensus among interested participants.

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

Some discussions were lively and occasionally tense but ultimately led to rough consensus. Two notable examples:

* CBOR-tagged CMWs [CN-tag-thread] - discussion on clarifying the usage of CBOR tags to identify CMWs; consensus to keep TN-derived tags only
* Use of generic claims/extensions in JWT/CWT/ASN.1 [cmw-claim-issue] [id-pe-cmw-issue] - discussions on the merits of keeping `cmw` claims for JWT and CWT, and `id-pe-cmw` for ASN.1; consensus to keep the claims and address some of the concerns in future documents ([generic-id-conclusion])

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169
[id-pe-cmw-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/154
[generic-id-conclusion] https://mailarchive.ietf.org/arch/msg/rats/BOuynAn0LVKJse1YCRaBqIxmiYI/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly.

The CDDL included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL].

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders will be issued and confirmed following WGLC. No disclosures have been filed yet.

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.
No suggestion for designated expert.

# CMW Shepherd write-up

## Document history

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?

Development of the draft began as a small-group effort. This snowballed as more documents and use-cases found a need for it. It has been consistently discussed at IETF meetings over the last few years.
Reviews and comments were received from many WG members through the IETF meetings, mailing list, and GitHub, resulting in lots of progress. There is strong consensus among interested participants.

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

Some discussions—especially on the CBOR tagging encoding [CN-tag-thread]—were lively and occasionally tense but ultimately led to rough consensus. There have also been issues for which an outcome was slow to reach [cmw-claim-issue], but with consensus nonetheless.

[CN-tag-thread] https://mailarchive.ietf.org/arch/msg/rats/q2pWU0MbbfddBZnngJHUqCR7FLM/
[cmw-claim-issue] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/issues/169

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

I am not aware of any such instances.

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 recommends) or elsewhere (where)?

The "Implementation Status" section of the document lists one existing Go implementation [Veraison-CMW] which covers all the features in the draft and is currently alpha-status.

[Veraison-CMW] https://github.com/veraison/cmw

## Additional reviews

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?

Development of the document included coordination with the LAMPS WG as users of the draft, as well as with the Trusted Computing Group SDO for a parallel standardisation effort of the same data format. Members from both of those groups have been involved in shaping CMW and keeping the efforts in sync.

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.

The draft requests IANA registrations for new media types, CBOR tags, JWT and CWT claims, and CoAP Content-Formats. Early IANA review has been performed and the feedback addressed [IANA-CF-fix].

The CDDL included in the draft, and the associated ABNF specification, have been reviewed and refined repeatedly, e.g. [ABNF-fix], [CBOR-tag-CDDL].

[IANA-CF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/191
[ABNF-fix] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/161
[CBOR-tag-CDDL] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/126

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools 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?

Document does not contain YANG modules.

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.

The ASN.1 module for the X.509 extension has been reviewed and validated using available tooling to check it compiles correctly.

[ASN1-check] https://mailarchive.ietf.org/arch/msg/rats/o2yOGNf8EE2d5bSodCGQHsgLTHM/

## Document shepherd checks

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. The document has gone through multiple cycles of WG and external review, and has demonstrated both clear utility and solid design. It is ready for AD evaluation.

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

This document would benefit from a review from the secdir. A review from IoT Directorate has already been performed on an early version (-04) [iotdir-review]. Issues relevant to these areas will be handled during IETF Last Call and IESG review. Any remaining feedback from area experts can be incorporated at that stage.

[iotdir-review] https://datatracker.ietf.org/doc/review-ietf-rats-msg-wrap-04-iotdir-early-sethi-2024-05-26/

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

Proposed Standard is being requested, which is appropriate given that the document defines a protocol-level data structure intended for use across implementations and specifications. Datatracker metadata reflects this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR disclosure reminders will be issued and confirmed following WGLC. No disclosures have been filed yet.

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.

Question was sent on mailing list [authorship-Q] and most have answered. Still pending from Henk and Hannes.

[authorship-Q] https://mailarchive.ietf.org/arch/msg/rats/vdnat1HgZ3km-3CXTCxF6CGikMc/

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

There are no outstanding, significant nits. The checker highlights a number of non-ASCII characters being used and misidentifies part of a media type as a FQDN.
The document conforms to the IETF content guidelines.

15. Should any informative references be normative or vice-versa? See the IESGStatement on Normative and Informative References.

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?

All normative references are freely available.

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

No normative downward references are present.

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 such references exist in this document.

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.

No changes to the status of existing RFCs are being made.

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

The IANA Considerations section is well-structured and matches the document’s protocol content. It identifies each new registration clearly, specifies allocation procedures, and uses consistent terminology. The new “RATS Conceptual Message Wrapper (CMW) Indicators Registry” is defined with clear initial contents and follows the guidance of RFC 8126.

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.

The draft introduces the “RATS Conceptual Message Wrapper (CMW) Indicators Registry,” which uses the Designated Expert policy. The instructions for the expert are clear and follow common IETF registry guidelines.
No suggestion for designated expert.