Attestation Event Stream Subscription
draft-ietf-rats-network-device-subscription-14

[Ballot discuss]
I will avoid reiterating points made in other DISCUSS ballots. My one unique concern is about the claim that this document does not introduce security considerations not already covered by referencing existing RFCs. RFC 9864 doesn't discuss streaming at all, and RFC 9863 only mentions it in the context that this very draft could address the need and implementations should consider which tools they need.

In the spirit of DISCUSSion, I'd like to ask the authors if they have considered the implications of switching from polling to subscribing?

If so and have rejected any of the streaming-specific edge cases as posing new security threats, that is worth explaining in the document. If such scenarios have not been considered, I would suggest that this section will need to be expanded after doing so. For example, Section 4.2.1 provides a normative MUST requirement for intervals of communication. What are the security implications if that isn't done to the other peer?

[Ballot comment]
I support the other DISCUSS ballots currently outstanding. Otherwise, I think is a mature document addressing a real issue that we should publish (once refined).

[Ballot discuss]

* 3.1
  * Really not comfortable with the idea of reusing a “nonce”.  When used as a nonce, it should never be reused.  Having an interchangeable name for a nonce as a “handle” only makes this harder to follow and understand.  Reading section 6 of [~[I-D.ietf-rats-reference-interaction-models](https://www.ietf.org/archive/id/draft-ietf-rats-network-device-subscription-13.html#I-D.ietf-rats-reference-interaction-models)~] did not resolve this reusability conundrum for me.  I think the right wording is more about “alternate” nonce sources to create freshness e.g. TPM-2.0.

* 3.2
  * `Methods of doing this verification vary based on the capabilities of the TPM cryptoprocessor used (see .`
    Where is the missing reference?

[Ballot comment]
Thanks to Joe S. for the SECDIR review and the additional follow up to note that the authors closed the items.
Thanks to Michael R. for the complete shepherd write up.

Thanks to the authors for this draft.

I generally support the DISCUSSes and Comments made by the other ADs; I won't list them all.

My only comment is that looking at the complexity of this and Med's comments/discusses, I wonder if YANG is really the best protocol for this application.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-rats-network-device-subscription-13
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Michael Richardson for the shepherd's concise write-up including the WG consensus *but* it lacks the justification of the intended status.

Please note that Tim Hollebeek is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-rats-network-device-subscription/reviewrequest/24254/

I hope that this review helps to improve the document,

Regards,

-éric

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

## DISCUSS (blocking)

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


### Section 3.1.1

How can `The terminology mapping is as follows` between RATS WG documents happen ? Was there any consensus reached on these RATS WG documents ? It does not seem so as there is a need 'to map terminology'. it only obscures the specifications... Let's put the onus on the documents' authors rather than on readers, implementers, and operators.

Or did I miss something ?

### Section 3.2.2

Why not "MUST" in ` new  SHOULD be generated` and in `a new TPM Quote notification SHOULD be sent` ?

See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 4.3.1

Why not a "MUST" in `It SHOULD be emitted no less than the  after the PCR is first extended` ?

I will trust the responsible AD to check for other SHOULD including one in 4.3.2, which is even combined with a "MUST" in `This notification SHOULD be emitted as soon as a TPM Quote can extract the latest PCR hashed values. This notification MUST be emitted` ;-)

[Ballot comment]

## COMMENTS (non-blocking)

### draft.ietf-rats-reference-interaction-models

I cannot refrain from wondering about `these documents are based on the challenge-response interaction model (CHARRA in Section 7.1 of [I-D.ietf-rats-reference-interaction-models]), which has limitations`, which is not yet requested for publication. I.e., it seems that the drafts have been requested for publication out of orders.

Why didn't the RATS WG only specify this technique ?

At least, it is rightfully flagged as a normative reference.

### Section 1

While `TPM` is listed in the RPC abbreviations, suggest to expand it at first use.

s/This means that the interval/This means that the *time* interval/

`All of these methods are out-of-band of an established subscription to YANG Notifications. Two alternative methods are taken into account by this document` I cannot reconcile the "all of these" with "two alternatives"... It is either "all" or "all but two alternatives".

[Ballot discuss]
Hi Henk, Eric, and Wei,

Thank you for the effort put into this document.

I must admit that it wasn’t an easy read but that’s OK as the document have a discussion on how to glue this piece with other RATS documents.

I don’t know if this was implemented or if issues such as the ones carried in NETCONF WG (e.g., YP-Lite, support of other transport mappings to accommodate (massive) distributed data) are relevant for this work. No action is needed at this stage, but I just wanted to let you know that work is happening.

Pointes are ordered per their appearance order in the document.

Please find below some comments for discussion:

# I don’t find where  in the doc.

CURRENT:
      These attestation
      notifications MUST at least include all the
      requested in the RPC.

# Is this 10 seconds frozen or configurable? Also, given the SHOULD out there, an implem may use a different value, how the value actually in use can be retrieved using the module?

CURRENT:
  *  every time at least one PCR has changed from a previous
      .  In this case, the notification SHOULD be
      emitted within 10 seconds of the corresponding  being
      sent:

# Why the container is needed here? adding that level increases the size of notifications

CURRENT:
      list attested-event {
        description
          "A set of events which extended an Attester PCR.  The
          sequence of elements represented in list must match the
          sequence of events placed into the TPM's PCR.";
        container attested-event {
          description
            "An instance of an event which extended an Attester PCR";

# Correlation

CURRENT:
        leaf-list pcr-index {
          type tpm:pcr;
          min-elements 1;
          description
            "PCR index number.";
        }
        leaf-list pcr-value {
          type binary;
          description
            "PCR value in a sequence which matches to the
            'pcr-index'.";
        }

## The description is not clear about the intended use.

## This structure imposes an ordering constraint that may lead to correlation issues. Why a list is not used here?

            +--ro pcr-values* [pcr-index]
                +--ro pcr-index    pcr
                +--ro pcr-value?  binary

# YANG Validation

There are some points to fix:

./yang/ietf-tpm-remote-attestation-stream.yang:49: warning: RFC 8407: 3.1: The IETF Trust Copyright statement seems to be missing or is not correct (see pyang --ietf-help for details).
./yang/ietf-tpm-remote-attestation-stream.yang:120: warning: the module seems to use RFC 2119 keywords, but the required text from RFC 8174 is not found or is not correct (see pyang --ietf-help for details).
./yang/ietf-tpm-remote-attestation-stream.yang:292: warning: RFC 8407: 4.4: statement "config" is given with its default value "true"

## Some can fixed by following the template in 9907

## Add the keywords boilerplate to the description of the module

# I don’t understand the following, especially how the intend of this MUST and how it will be followed.

CURRENT:
  It is possible to
  use either YANG subscription methods to other YANG modules for RATS
  Conceptual Messages or to define Event Streams for other none-YANG-
  modeled data.  In the context of RATS Conceptual Messages, both
  options MUST be a specified via YANG augments to this specification.

# BCP 216

The document does not follow many of the templates in 9907. In particular, please follow the security template provided in https://datatracker.ietf.org/doc/html/rfc9907#name-security-considerations-sect.

[Ballot comment]
# PCR was used without being defined. Please update Section 2 accordingly. 

# Please avoid use “YANG model”. Overall, refer to the guidance in Section 2.5 of RFC9907.

# Notations

Please consider adding some text to explain how to read the various notations our there (e.g., ? in the excerpt below):

CURRENT:

|    |<----------------- subscribe(nonce, TpmName, ?PcrSelection) |    |
|    | {nonce} -------------------------------------------------->|    |

# Tree diagrams: RFC8340

Please add a note early in the document about the tree diagrams.

As a reminder, RFC9907 says:

  If YANG tree diagrams are used, then an informative reference to the
  YANG tree diagrams specification MUST be included in the document.

# I don’t parse this sentence:

CURRENT:
  *  If the ,  has incremented.  The
      existing subscription MUST be terminated, and a new  SHOULD be generated.

# Likewise, I don’t parse the following:

CURRENT:
  This is done via the augmentation of a  into
  [RFC8639] the  RPC. 

# Why both notifications will be provided? Shouldn’t this be “or”? (same comment for other similar constructs in the doc)

CURRENT:
  1.  and  notifications which
      include the provided .  These attestation
      notifications MUST at least include all the
      requested in the RPC.

# Consider adding an appendix with the full tree.

# Please replace with the RFC number + title

CURRENT:
    import ietf-tpm-remote-attestation {
      prefix tpm;
      reference
        "draft-ietf-rats-yang-tpm-charra";
    }


# Add a reference statement

CURRENT:
    import ietf-tcg-algs {
      prefix taa;
    }

# Please update to follow the template at https://datatracker.ietf.org/doc/html/rfc9907#name-template-for-ietf-modules 

CURRENT:
    organization "IETF";
    contact
      "WG Web: 
        WG List: 

        Editor:  Eric Voit
                  ";

    description
      "This module contains YANG specification for subscribing
        to attestation streams which contain events that have
        been generated by TPM chips or equivalent hardware
        implementations that include the protected capabilities
        as provided by TPMs.

        Copyright (c) 2024 IETF Trust and the persons identified
        as authors of the code. All rights reserved.

        Redistribution and use in source and binary forms, with
        or without modification, is permitted pursuant to, and
        subject to the license terms contained in, the Simplified
        BSD License set forth in Section 4.c of the IETF Trust's
        Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
        itself for full legal notices.";

# The revision date MUST match the one used in the file name + update reference to include the document title

CURENT:
    revision 2024-07-06 {
      description
        "Initial version.";
      reference
        "draft-ietf-rats-network-device-subscription";

# Please use meaningful description as the module will be consumed out of the RFC

CURRENT:
    identity pcr-unsubscribable {
      base sn:establish-subscription-error;
      description
        "Requested PCR is unsubscribable by the Attester.";
    }

# Add prefix

OLD:
    augment "/sn:establish-subscription/sn:input" {
      when 'derived-from-or-self(sn:stream, "attestation")';

NEW:
    augment "/sn:establish-subscription/sn:input" {
      when 'derived-from-or-self(sn:stream, "tras:attestation")';

# binary instead of structured data

Please consider adding some text to explain why binary is used rather than a more structured data

# List names

RFC9907 says:
“List identifiers SHOULD be singular with the surrounding container name plural. Similarly, "leaf-list" identifiers SHOULD be singular.”

Please make this change:

OLD:
      list unsigned-pcr-values {
        description
          "Allows notifications to be filtered by PCR number or
          PCR value based on via YANG related mechanisms such as PATH.

NEW:
      list unsigned-pcr-value {
        description
          "Allows notifications to be filtered by PCR number or
          PCR value based on via YANG related mechanisms such as PATH.

# Missing units + reference for the default value

CURRENT:
      leaf marshalling-period {
        type uint8;
        default 5;
        description
          "The maximum number of seconds between the time an event
          extends a PCR, and the 'tpm-extend' notification which
          reports it to a subscribed Verifier.  This period allows
          multiple extend operations bundled together and handled as a
          group.";
      }

## Please add units statement

## Also, can we have a reference where the default value is defined?

# Other as Security Consideration

CURRENT:
8.3.  Other

  There are no additional security considerations introduced by this
  document.

I suggest to remove this as it is misleading.

# IANA

Please update IANA requests to follow the template in https://datatracker.ietf.org/doc/html/rfc9907#name-iana-template-for-documents

# Missing Examples

RFC9907 says:
  Each specification that defines one or more modules SHOULD contain
  usage examples, either throughout the document or in an appendix.

Consider adding some examples to illustrate the use of the module.

# Nits

## s/such as a Verifiers or a Relying Parties/such as a Verifier or a Relying Party

## Please fix the following

CURRENT:
  The second adverse effect stems from the use of nonces in the
  challenge-response interaction model Section 7.1 of
  [I-D.ietf-rats-reference-interaction-models] realized in [RFC9684].

##

OLD:
  The
  operational model and corresponding sequence diagram described in
  this section is based on [RFC9684]

NEW:
  The
  operational model and corresponding sequence diagram described in
  this section are based on [RFC9684]

# s/diagram focusses on matching/diagram focuses on matching

#

OLD:
at that time.Methods of doing this verification vary based on the

NEW:
at that time. Methods of doing this verification vary based on the

# Clarity

OLD:
  Therefore, a Verifier MUST periodically issue a new nonce and
  receive this nonce within a TPM quote response in order to ensure the
  freshness of the results. 

NEW:
  Therefore, a Verifier MUST periodically issue a new nonce and
  MUST receive this nonce within a TPM quote response in order to ensure the
  freshness of the results. 

# s/Evidence to assists a Verifier/Evidence to assist a Verifier

Cheers,
Med

[Ballot comment]
Section 3.2.2, paragraph 1
>    The [RFC8639] notification format includes the  object.
>    This can be used to determine the amount of time after the initial
>    subscription each notification was sent.  However, this time is not
>    returned as part of the signed results of the TPM Quote and therefore
>    is not as trustworthy as the objects included in the TPM Quote.
>    Therefore, a Verifier MUST periodically issue a new nonce and receive
>    this nonce within a TPM quote response in order to ensure the
>    freshness of the results.  This can be done using the    challenge-response-attestation> RPC from [RFC9684].
>
> 3.2.2.  TPM 2 Quote
>
>    When the Attester includes a TPM2-compliant cryptoprocessor, internal
>    time-related counters are included within the signed TPM Quote and
>    thereby are trustworthy.  By including an initial nonce in the
>    [RFC8639] subscription request, fresh values for these counters are
>    pushed to the Verifier as part of the first TPM Quote.  In order to
>    assess the freshness of the TPM Quotes that the Attester continuesly
>    generates over time, the Verifier can aquire separate TPM Quotes via
>    the  RPC from [RFC9684] out-of-
>    band.  These separate TPM Quotes include fresh time-related counters
>    that can be appraised for freshness based on the predictable
>    incrementing of these time-related counters.  An example for how that
>    can be realized is illustared in [I-D.birkholz-rats-tuda].

I support Gorry's DISCUSS on two points.

1a) The reference to I-D.birkholz-rats-tuda which expired in 2022, and
    was never adopted as a WG item must be resolved. This document can
    either

    - incorporate the relevant concepts (epoch-based nonce distribution)
      directly if it is normatively required or

    - remove the reference and rewrite the text around it.

1b) In Section 3.1, the word "periodically" is undefined normative
    language. There is no guidance on how frequently nonces must be
    refreshed, what determines an adequate interval, or how this
    interacts with the subscription heartbeat. This MUST should either
    specify a concrete bound or be recast with appropriate qualitative
    guidance.

Section 5, paragraph 3
>      import ietf-tcg-algs {
>        prefix taa;
>      }

Please add a reference clause that refers to the document that contains
this module.

Section 5, paragraph 8
>      revision 2026-06-16 {
>        description
>          "Final Version";
>        reference
>          "draft-ietf-rats-network-device-subscription";
>      }

The description should say "Initial Version". The
reference to itself should say something like
"RFC XXXX: Attestation Event Stream Subscription"
with a note to the RFC Editor to replace the XXXX with
the RFC number assigned to the document.

Section 5, paragraph 11
>        leaf tpm20-subscription-heartbeat {
>          type uint16;
>          units "seconds";
>          description
>            "Number of seconds before the Attestation stream should send
>            a new notification with a fresh quote.  This allows
>            confirmation that the PCR values haven't changed since the
>            last tpm20-attestation.";
>        }
>      }

Section 4.2.1 states a MUST: "For TPM 2.0, every requested PCR MUST
appear in a  notification no less frequently than
the heartbeat interval." However, here in the module, the leaf is

- Not mandatory (no mandatory true)
- Has no default value
- Has type uint16 with no minimum constraint (allowing 0)

If heartbeat is not configured or is set to 0, the MUST in 4.2.1
becomes meaningless. The document should either: provide a mandatory
default (e.g., 3600 seconds), explicitly state the MUST only
applies when heartbeat is configured, or add appropriate
YANG constraints.

Similarly, the per-TPM YANG augmentation does not include heartbeat
configuration, yet the heartbeat is specified platform-wide —
it's unclear how this interacts with per-TPM subscriptions.

Section 5, paragraph 12
>        leaf-list pcr-index {
>          type tpm:pcr;
>          min-elements 1;
>          description
>            "The numbers/indexes of the PCRs. This will act as a filter
>            for the subscription so that 'tpm-extend' notifications
>            related to non-requested PCRs will not be sent to a
>            subscriber.";
>        }
>      }

Section 3.1.1 states: "Optional 'pcr-index'... When no PCRs are selected,
all PCR banks are returned."

However, this subscription augmentation in YANG requires min-elements 1
on pcr-index, making PCR specification mandatory in a subscription.
The quoted text is describing the behaviour of the challenge-response RPC,
not the subscription, but the juxtaposition is confusing. A reader
could reasonably conclude that they can subscribe without specifying
PCR indices (and get all banks) — which the YANG forbids. The text
should be revised to make clear that the PCR selection behaviour
described refers to the challenge-response RPC, and that the
subscription model requires explicit PCR specification.

Section 5, paragraph 14
>              case netequip-boot-event-log {
>                if-feature "tpm:netequip_boot";
>                description
>                  "IMA event log format";

The description is incorrect. I think you meant
something like "Network equipment boot event log format".

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-rats-yang-tpm-charra], and [RFC6010].

DOWNREF [RFC9683] from this Proposed Standard to Informational RFC9683. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

[Ballot comment]
Thanks for providing this document. I do not see any transport-protocol related concerns. The following NiTs are noted here to update the next revision:

/time.Methods/ - Insert space.
/As there is no new Verifier nonce provided at time.../ - I wasn't sure whether this was specific to the example or a general principle, perhaps the text ought to refer to the figure?
/...and therefore is not trustworthy as objects returned as part of the Quote.../ - I couldn't parse this - is it "because this not trustworthy because the object is not returned as a part of the TPM Quote" or something else?
/ then the TPM Quote may be considered fresh. / - I wondered why this was stated as a may (i.e. might or might not), rather than a fact, i.e. "is considered fresh".
/If available, chip specific maximum drifts SHOULD be considered/ - it's already conditional, could that clause be a MUST?
/This  Event Stream may only be exposed/ - to avoid any doubt, is this "will only be exposed" or "can only be exposed"  or something else?

I see draft-birkholz-rats-tuda -- Expired Internet-Draft (Individual), I'm hoping this an example of how to do something, rather than a required method. If it is the former, please explain if it is an example, or propose a way to avoid the dependency on this spec. For instance, importing the salient concepts (see Shepherd writeup 2025-12-03).

Thank you for the updated revision (-13) that resolves my DISCUSS relating to the way in which [I-D.birkholz-rats-tuda] was cited.

Best wishes,
Gorry

[Ballot comment]
# IESG review of draft-ietf-rats-network-device-subscription-12

CC @MikeBishop

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

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### URLs

These URLs point to tools.ietf.org, which has been taken out of service:

* http://tools.ietf.org/wg/rats/

### Grammar/style

#### Section 1, paragraph 1
```
nterested RATS entities, such as a Verifiers or a Relying Parties, can be una
                                ^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^
```
The plural nouns "Verifiers" and "Parties" cannot be used with the article "a".
Did you mean "a Verifier" or "Verifiers" / "a Relying Party" or "Relying Parties"?

#### Section 2, paragraph 1
```
red in Section 6. The following sub-section focuses on subscription to YANG
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.1.2, paragraph 2 and 11
```
s occurs when a PCR is extended subsequent to time(EG). Immediately after th
                                ^^^^^^^^^^^^^
```
```
to determine the amount of time subsequent to the initial subscription each n
                                ^^^^^^^^^^^^^
```
Consider using "after".

#### Section 3.2, paragraph 1
```
  at that time.Methods of doing this verification vary based on the
                ^
```

A space appears to be missing.

#### Section 5, paragraph 17
```
station Evidence as defined in Section Section 4, additional Event Streams ca
                              ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 8.2, paragraph 1
```
  The security requirements (Section 4.2.5 of [RFC7923]) and the
  security considerations (Section 5 of [RFC7923]) from RFC7923
  (Requirements for Subscription to YANG Datastores) apply.
```

Consider having only a single mention of RFC7923 in this sentence, with just the
section numbers in the parentheses.

[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

I support Gorry Fairhurst's DISCUSS position.

** list unsigned-pcr-values {
        description
          "Allows notifications to be filtered by PCR number or
          PCR value based on via YANG related mechanisms such as PATH.
          This is done without requiring the filtering structure to be
          applied against TCG structured data.";
Is there a reference for “TCG structured data”?

** uses tpm:tpm20-attestation {
        description
          "Provides the attestation info.  Also ensures PCRs can be
          XPATH filtered by refining the unsigned data so that it
          appears.";
Should there be a reference to XPath here?

[Ballot discuss]
Thank you for the work that has been put into this document. Please find below one blocking DISCUSS point (easy to address), and some non-blocking COMMENT points/nits.

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

I'm unsure what is actually intended by the text that says:
  /As shown by [I-D.birkholz-rats-tuda],
  subsequent TPM Quotes delivered to the Verifier out-of-band can be
  appraised for freshness based on the predictable incrementing of
  these time-related counters./
I also see that draft-birkholz-rats-tuda is an Expired Internet-Draft (Individual). I'm hoping this an example of how to do something, rather than a method needed to realise the spec. If it is the former, please explain that this it is an example.  If the method is needed, please propose a way to avoid the dependency on this work-in-progress. For instance, importing the salient concepts (see Shepherd writeup 2025-12-03).

[Ballot comment]
Thanks for providing this document. I do not see any transport-protocol related concerns. The following NiTs are noted here to update the next revision:

/time.Methods/ - Insert space.
/As there is no new Verifier nonce provided at time.../ - I wasn't sure whether this was specific to the example or a general principle, perhaps the text ought to refer to the figure?
/...and therefore is not trustworthy as objects returned as part of the Quote.../ - I couldn't parse this - is it "because this not trustworthy because the object is not returned as a part of the TPM Quote" or something else?
/ then the TPM Quote may be considered fresh. / - I wondered why this was stated as a may (i.e. might or might not), rather than a fact, i.e. "is considered fresh".
/If available, chip specific maximum drifts SHOULD be considered/ - it's already conditional, could that clause be a MUST?
/This  Event Stream may only be exposed/ - to avoid any doubt, is this "will only be exposed" or "can only be exposed"  or something else?

I see draft-birkholz-rats-tuda -- Expired Internet-Draft (Individual), I'm hoping this an example of how to do something, rather than a required method. If it is the former, please explain if it is an example, or propose a way to avoid the dependency on this spec. For instance, importing the salient concepts (see Shepherd writeup 2025-12-03).

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-rats-network-device-subscription-11. If any part of this review is inaccurate, please let us know.

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

First, in the ns registry in the IETF XML Registry group located at:

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

a single new namespace will be registered as follows:

ID: yang:ietf-tpm-remote-attestation-stream
URI: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

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

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

a single new YANG module will be registered as follows:

Name: ietf-tpm-remote-attestation-stream
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream
Prefix: tras
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

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

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

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-04-13):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-rats-network-device-subscription@ietf.org, mcr+ietf@sandelman.ca, rats-chairs@ietf.org, rats@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Attestation Event Stream Subscription) to Proposed Standard


The IESG has received a request from the Remote ATtestation ProcedureS WG
(rats) to consider the following document: - 'Attestation Event Stream
Subscription'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-04-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


  This document defines how to subscribe to YANG Event Streams for
  Remote Attestation Procedures (RATS).  Specifically, this document
  defines a YANG module that augments the YANG module for TPM-based
  Challenge-Response Remote Attestation (CHARRA), enabling subscription
  to RATS Conceptual Messages of the Evidence type and auxiliary Event
  Logs as part of that Evidence.  The module defined requires that at
  least one TPM 1.2 or TPM 2.0 (or equivalent hardware implementation
  providing the same protected capabilities as a TPM) must be available
  on the Attester on which the YANG server is running.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rats-network-device-subscription/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4406/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9683: Remote Integrity Verification of Network Devices Containing Trusted Platform Modules (Informational - Internet Engineering Task Force (IETF) stream)
    draft-ietf-rats-reference-interaction-models: Reference Interaction Models for Remote Attestation Procedures (None - Internet Engineering Task Force (IETF) stream)

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

THIS WRITE UP STARTED: 2025-11-10.
THIS WRITE UP POSTED:  2025-12-03
VERSION REVIEWED: draft-ietf-rats-network-device-subscription-07

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

The document received good comments and reviews, and many people are happy
with the document, with little in the way of controversy.

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

No.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document? Have a significant number of potential implementers indicated

No.

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

N/A

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

There is YANG, and it received an early YANG-Doctor review in 2022, which was
acted upon.

>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?

Yes.

>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 YANG underwent compilation tests.

>Document Shepherd Checks
>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?

The document is needed.

> 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?

No.

> 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?

The DT is correct, and Proposed Standard is the correct track.

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

The authors were aware of the notewell.

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

Yes.

> 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 some references that could be updated.

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

There remain a number of references to not-adopted, expired WIP documents,
such as birkholz-rats-tuda.  It seems like it should be normative.
It could be that the relevant part could be brought into this document by
value rathe rather than reference.

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

None.
The TPM 2.0 specification is available on the TCG site, and the IEC copy of
it is available without fee.

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

RFC9334 needs to be added to downref list.
I-D.ietf-rats-reference-interaction-models will also need a downref.

> 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?

I-D.ietf-rats-reference-interaction-models is in WGLC, but note that it is
Informational, and will need a downref.

>Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,

Only a YANG URI namespace registration is done, and it looks fine.

> List any new IANA registries that require Designated Expert Review for

None.

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

THIS WRITE UP STARTED: 2025-11-10.
THIS WRITE UP POSTED:  2025-12-03
VERSION REVIEWED: draft-ietf-rats-network-device-subscription-07

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

The document received good comments and reviews, and many people are happy
with the document, with little in the way of controversy.

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

No.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document? Have a significant number of potential implementers indicated

No.

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

N/A

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

There is YANG, and it received an early YANG-Doctor review in 2022, which was
acted upon.

>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?

Yes.

>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 YANG underwent compilation tests.

>Document Shepherd Checks
>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?

The document is needed.

> 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?

No.

> 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?

The DT is correct, and Proposed Standard is the correct track.

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

The authors were aware of the notewell.

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

Yes.

> 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 some references that could be updated.

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

There remain a number of references to not-adopted, expired WIP documents,
such as birkholz-rats-tuda.  It seems like it should be normative.
It could be that the relevant part could be brought into this document by
value rathe rather than reference.

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

None.
The TPM 2.0 specification is available on the TCG site, and the IEC copy of
it is available without fee.

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

RFC9334 needs to be added to downref list.
I-D.ietf-rats-reference-interaction-models will also need a downref.

> 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?

I-D.ietf-rats-reference-interaction-models is in WGLC, but note that it is
Informational, and will need a downref.

>Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,

Only a YANG URI namespace registration is done, and it looks fine.

> List any new IANA registries that require Designated Expert Review for

None.

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

THIS WRITE UP STARTED: 2025-11-10.
THIS WRITE UP POSTED:  2025-11-27
VERSION REVIEWED: draft-ietf-rats-network-device-subscription-07

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

The document received good comments and reviews, and many people are happy
with the document, with little in the way of controversy.

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

No.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document? Have a significant number of potential implementers indicated

No.

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

N/A

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

There is YANG, and it received an early YANG-Doctor review in 2022, which was
acted upon.

>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?

Yes.

>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 YANG underwent compilation tests.

>Document Shepherd Checks
>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?

The document is needed.

> 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?

No.

> 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?

Standards Track is requested.
ACTION: The DT does not yet reflect this status.

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

The authors were aware of the notewell.

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

Yes.

> 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 some references that could be updated.

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

There remain a number of references to not-adopted, expired WIP documents,
such as birkholz-rats-tuda.  It seems like it should be normative.
It could be that the relevant part could be brought into this document by
value rathe rather than reference.

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

None.
The TPM 2.0 specification is available on the TCG site, and the IEC copy of
it is available without fee.

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

RFC9334 needs to be added to downref list.
I-D.ietf-rats-reference-interaction-models will also need a downref.

> 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?

I-D.ietf-rats-reference-interaction-models is in WGLC, but note that it is
Informational, and will need a downref.

>Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,

Only a YANG URI namespace registration is done, and it looks fine.

> List any new IANA registries that require Designated Expert Review for

None.