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

Section 3.2.2, paragraph 1
>    The [RFC8639] notification format includes the <eventTime> 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 <tpm12-
>    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 <tpm12-challenge-response-attestation> 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 <tpm20-attestation> 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.)

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

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?