Trusted Execution Environment Provisioning (TEEP) Protocol
draft-ietf-teep-protocol-26

[Ballot comment]
Thank you to Paul Kyzivat for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Congrats to the WG on completing this core protocol specification.

[Ballot comment]
Hi Hannes, all,

All my comments in my previous ballot [1] are addressed in [2]. Thank you.

I noticed the following when checking the new version:
(27/02 Update: all these were addressed by Hannes in https://author-tools.ietf.org/iddiff?url1=draft-ietf-teep-protocol-24&url2=draft-ietf-teep-protocol-25&difftype=--html)

# Broken heading: OPS section is a separate section, not a subsection of sec section

OLD:
  10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
    10.1.  Operational Considerations . . . . . . . . . . . . . . .  51

NEW:
  10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
  11.  Operational Considerations . . . . . . . . . . . . . . .  51

# 0 is a reserved/not allowed type value

CURRENT:
  ; message type numbers, in one byte which could take a
  ; number from 0 to 23
  $teep-type /= (0..23)

I would align the CDDL with the intended usage. Having a mention that 0 is reserved and MUST NOT be used would be sufficient.

# Inconsistency

Some text clean-up is needed here as its says contradicting things:

CURRENT (4.6):
  err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message.  Note that error
      codes are restricted to the range (0..23) to permit encoding as
      single-byte CBOR unsigned integers.  Error code values 0, 11-16,
      and 18-22 are currently unassigned and reserved for future use.
      Error code 0 is intentionally reserved to prevent accidental use.

NEW:
  err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message. Error code values 11-16,
      and 18-22 are currently unassigned and reserved for future use.

# Specification Required policy: Missing Guideline for DEs

You have several ranges that are governed by Specification Required policy. That policy involves experts per rfc8126#section-4.6:

  For the Specification Required policy, review and approval by a
  designated expert (see Section 5) is required, and the values and
  their meanings must be documented in a permanent and readily
  available public specification, in sufficient detail so that
  interoperability between independent implementations is possible.
  This policy is the same as Expert Review, with the additional

Some guidance to help DEs perform reviews would be needed here per rfc8126#section-4.5:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.  It is particularly important to lay out what should be
  considered when performing an evaluation and reasons for rejecting a
  request.  It is also a good idea to include, when possible, a sense
  of whether many registrations are expected over time, or if the
  registry is expected to be updated infrequently or in exceptional
  circumstances only.

# Guidance for authors/experts/IANA?

Section 13.6 says:

  Any new cipher suites MUST provide authentication, integrity, and
  SHOULD provide confidentiality protection.

The normative requirements can be moved to the main body of the spec. You formulate it as a guidance for DEs.

Please check “Inappropriate Uses of Key Words” in https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ for the matter.

# Add RFC 8792 to your references as that is needed to unfold the examples.

CURRENT:
CBOR Diagnostic Notation of SUIT Manifest

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

You may add the following at the end of your section 2:

NEW:
  Examples are folded following the conventions in [RFC8792].

# Replace teep-success with success (3 occurrences)

CURRENT:
D.5.1.  CBOR Diagnostic Notation

  / teep-success = /
  [
    / type: / 5 / TEEP-TYPE-teep-success /,
    / options: /
    {
      / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF'
    }
  ]

D.5.2.  CBOR Binary Representation

  82                  # array(2)
      05              # unsigned(5) / TEEP-TYPE-teep-success /
      A1              # map(1)
        14            # unsigned(20) / token: /
        50            # bytes(16)
            A0A1A2A3A4A5A6A7A8A9AAABACADAEAF

# Replace teep-error with error (3 occurrences)


CURRENT:
D.6.1.  CBOR Diagnostic Notation

  / teep-error = /
  [
    / type: / 6 / TEEP-TYPE-teep-error /,
    / options: /
    {
      / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF',
      / err-msg / 12 : "disk-full"
    },
    / err-code: / 17 / ERR_MANIFEST_PROCESSING_FAILED /
  ]

D.6.2.  CBOR binary Representation

  83                  # array(3)
      06              # unsigned(6) / TEEP-TYPE-teep-error /

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-teep-protocol-23&url2=draft-ietf-teep-protocol-24&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/teep/EtIwDcTHKHxr0y8-6xUzAdMY8RQ/

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

Also, thanks for the updates to address the points in my previous DISCUSS ballot in v26.

However, here are a few comments/suggestions on the updated text in v26:

1) Please fix the section references:
The registries in Sections 13.2 through 13.6 are to be created within this registry group.

2) On the DE guidance.
The request does not conflict with active IETF work in related areas.

I assume this needs to be qualified as "When the request is coming from outside of the IETF, ..."?

3) I would urge the authors and the WG to reconsider whether they wanted to expand the Standards Action range and perhaps do a 50-50% split between Standards Action and Specification Required. I get the impression that the Specification Required is meant to mainly cater to allocations from outside the IETF and if so, please consider whether the range for IETF is sufficient and if any such range preferences are required to be spelled out in the registry or in DE guidance. Obviously I don't know enough about this work to say anything further - so, this is just a point for your consideration.

[Ballot discuss]
** Section 13.2, 13.3, 13.4, 13.5, 13.6, 13.7

-- The user of “reserved for future use” in these registries is inconsistent with defining the ranges as having a Specification Required allocation policy

==[ snip from IANA’s review ]==
1) The tables that initialize the new registries repeatedly describe ranges as "(Reserved for future use)", but also assign registration procedures to those ranges. If these values are available for assignment, the string "(Reserved for future use)" needs to be changed to "Unassigned". The RFC 8126 definition of "Reserved" is essentially "not available for assignment." Furthermore, the registration procedures for many of these values is Specification Required, but unless the specification is an IETF Stream RFC, the spec would not be able to release a reserved value.
==[ snip ]==

-- The Specification Required ranges need guidance for the designated expert

==[ snip from IANA’s review ]==
2) Please add guidance for the designated experts who are going to review requests for registration in the Specification Required range. See RFC 8126, Section 5.3 for advice. (If the same guidance will apply to all of the registries, one way to approach this would be to add a single subsection to the end of the section.)
==[ snip ]==

[Ballot comment]
Thank you to Paul Kyzivat for the GENART review.

Thank you to the responsible AD and IESG for resolving one of my DISCUSS feedback items during the 29-Feb telechat.

** Section 4.6
  err-lang
      The err-lang parameter is an optional RFC 5646 [RFC5646] language
      tag identifying the language of the err-msg text.  When present,
      implementations SHOULD use the language tag to aid human operators
      in interpreting diagnostic text.  The err-msg field SHOULD be
      formatted in the language indicated by this tag. 

What is the circumstance under which it would be appropriate for the err-msg field to be formatting in a language other than the one specified by the language tag (i.e., why would a mismatch be appropriate or allowed especially since the language tag is optional)?

** Section 10.1.  Consider if these are adequately specified for interoperability:
  *  Key and certificate lifecycle: Operators MUST run procedures for
      certificate and key issuance, rollover, revocation, and timely
      renewal.

-- We have a normative MUST here, but not guidance on what is appropriate or “timely”.  This seems very contextual.

  *  Time synchronization: Accurate device time is important for
      certificate validity checks and for some attestation freshness
      mechanisms.  Operators SHOULD ensure devices maintain adequate
      time synchronization.

-- What is “adequate” enough?

  *  Transport and deployment-specific concerns: TEEP is transport
      agnostic; operators MUST ensure the chosen transport provides
      adequate confidentiality, integrity, authentication, and replay
      protection.
-- What makes something “_adequate_ confidentiality …”

** Appendix B.  Editorial.

  Finally, we would like to thank the following IESG members for their
  review feedback: Sean Turner, Paul Kyzivat, Scott Hollenbeck, Luigi
  Iannone, Paul Wouters, and Yoshifumi Nishida

Typo Only one individual listed here is on the IESG.

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-teep-protocol-24
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).

Other thanks to Eliot Lear, the IoT directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-teep-protocol-23-iotdir-telechat-lear-2026-02-08/ (and I have yet to read a reply from the authors)

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.

## COMMENTS (non-blocking)

### IoT directorate review and section 4.1.1

As noted above, Eliot did an extensive review and has provided feedback, his points about section 4.1.1 should really be addressed.

### Section 3

Who is the "we" in `we assume them ` ? The authors ? The WG ? The IETF community ? Please avoid ambiguities.

Possibly also in other places.

### Section 4.2

Why not a MUST in `The TAM SHOULD set an expiration time for each token` ? Also note that guidance must be given if "SHOULD" is kept. See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (cfr the guidance/exception given for a SHOULD in section 4.3.1)

### Section 4.2

Please add text about data-item-requested being a registry defined in section 13.3 (which is good idea).

### Section 13.3

Suggest to have at least one code point for "private use" per RFC 8126

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
Thanks to Sean Turner for their secdir reviews.

Section 5, second to last para:  Perhaps make this more clear (the sentence is very long).  'and if not then attempt', perhaps 'and if not accepted as trustworthy, then attempt'.  Of course if that is not the intended meaning, then please clarify.

Section 6:  Label 22 appears to be assigned, contrary to the text in para 2.

Section 10, Cryptographic Algorithms:  Please reference RFC9459 here, to explain the use of CTR mode (not an AEAD mode).  Technically, one can get to that RFC via the suit mti draft, but why not reference it explicitly? 

I support both Ketan and Roman's discuss positions.

[Ballot discuss]
** To the responsible AD of the document: idnits reports:
  ** Downref: Normative reference to an Informational RFC: RFC 9397

RFC9397 wasn’t called out in the IETF LC.  It also is not in the downref registry.  We need to confirm with the IESG on the use of this reference to prevent the need for another IETF LC.

** Section 13.2, 13.3, 13.4, 13.5, 13.6, 13.7

-- The user of “reserved for future use” in these registries is inconsistent with defining the ranges as having a Specification Required allocation policy

==[ snip from IANA’s review ]==
1) The tables that initialize the new registries repeatedly describe ranges as "(Reserved for future use)", but also assign registration procedures to those ranges. If these values are available for assignment, the string "(Reserved for future use)" needs to be changed to "Unassigned". The RFC 8126 definition of "Reserved" is essentially "not available for assignment." Furthermore, the registration procedures for many of these values is Specification Required, but unless the specification is an IETF Stream RFC, the spec would not be able to release a reserved value.
==[ snip ]==

-- The Specification Required ranges need guidance for the designated expert

==[ snip from IANA’s review ]==
2) Please add guidance for the designated experts who are going to review requests for registration in the Specification Required range. See RFC 8126, Section 5.3 for advice. (If the same guidance will apply to all of the registries, one way to approach this would be to add a single subsection to the end of the section.)
==[ snip ]==

[Ballot comment]
Thank you to Paul Kyzivat for the GENART review.

** Section 4.6
  err-lang
      The err-lang parameter is an optional RFC 5646 [RFC5646] language
      tag identifying the language of the err-msg text.  When present,
      implementations SHOULD use the language tag to aid human operators
      in interpreting diagnostic text.  The err-msg field SHOULD be
      formatted in the language indicated by this tag. 

What is the circumstance under which it would be appropriate for the err-msg field to be formatting in a language other than the one specified by the language tag (i.e., why would a mismatch be appropriate or allowed especially since the language tag is optional)?

** Section 10.1.  Consider if these are adequately specified for interoperability:
  *  Key and certificate lifecycle: Operators MUST run procedures for
      certificate and key issuance, rollover, revocation, and timely
      renewal.

-- We have a normative MUST here, but not guidance on what is appropriate or “timely”.  This seems very contextual.

  *  Time synchronization: Accurate device time is important for
      certificate validity checks and for some attestation freshness
      mechanisms.  Operators SHOULD ensure devices maintain adequate
      time synchronization.

-- What is “adequate” enough?

  *  Transport and deployment-specific concerns: TEEP is transport
      agnostic; operators MUST ensure the chosen transport provides
      adequate confidentiality, integrity, authentication, and replay
      protection.
-- What makes something “_adequate_ confidentiality …”

** Appendix B.  Editorial.

  Finally, we would like to thank the following IESG members for their
  review feedback: Sean Turner, Paul Kyzivat, Scott Hollenbeck, Luigi
  Iannone, Paul Wouters, and Yoshifumi Nishida

Typo Only one individual listed here is on the IESG.

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

I have a few discussion points related to the IANA considerations that should be straightforward to address.

1) I believe this document needs to instruct the IANA to create a new registry group - perhaps "Trusted Execution Environment Provisioning (TEEP) Protocol Parameters" registry group? All the registries mentioned in sections 13.2 through 13.7 are then to be created within this new registry group?

2) When the IANA section says "Reserved for future use", I believe those are "unassigned" (i.e., other docs/specs may ask for their allocation to IANA)? While when "Reserved" is used, it is an instruction for IANA to not allocate those values? Please check since some values that are "Reserved" (see below) might actually be "deprecated" ? Also, please indicate that the allocations given in the tables are the initial allocations being made by this document.

4 (Reserved) This document

3) There are registries with "Specification Required" but no guidance has been provided for DEs as required per RFC8126. Please provide DE guidance or alternately use IETF Review policy instead of Specification Required if allocations are going to done only from within the IETF.

4) For the TEEP CBOR Label Registry (section 13.5), is there an upper bound? Can someone ask IANA for allocating a very high random number?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-teep-protocol-24

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-teep-protocol-24.txt

# idnits report displays few warnings

# This document is not an easy read (i am not a security expert) and have only performed a high level review. The sections i processed were well written.

# i have only one observation:

19   This document specifies a protocol that installs, updates, and
20   deletes Trusted Components in a device with a Trusted Execution
21   Environment (TEE).  This specification defines an interoperable
22   protocol for managing the lifecycle of Trusted Components.

GV> The abstract says that it defines an interoperable protocol. Is that not implicit when a protocol is used by different devices? Maybe my question is what does 'interoperable' describe in the context of the abstract?

What about the following abstract (AI generated)

"
  This document specifies the Trusted Execution Environment Provisioning
  (TEEP) Protocol, which enables secure lifecycle management of Trusted
  Components in devices with a Trusted Execution Environment (TEE).
  The protocol defines message exchanges between a Trusted Application
  Manager (TAM) and a TEEP Agent to query device state, convey
  attestation evidence, and install, update, or delete Trusted
  Components.  Messages are encoded in CBOR and secured using COSE.
"

Many thanks for this document,

Kind Regards,
Gunter Van de Velde

[Ballot comment]
# WIT AD comments for draft-ietf-teep-protocol-24

Thank you for the work on this document. Thank you to Yoshi for his TSV-ART review. I have no objection to the publication of this document as an RFC, but I do have comments that ought to be easy to address.

## Comments

### Section 3
A forward reference to Section 11 within Section 3 would have been helpful, e.g., after “The TEEP protocol is transport-agnostic; bindings to end-to-end security.  TEEP protocol messages are signed by the specific transports are defined in separate companion specifications.”

### Section 10
Is the following text correct and what does that really imply?:
“TEEP is transport
agnostic; operators MUST ensure the chosen transport provides
adequate confidentiality, integrity, authentication, and replay
protection.  See the HTTP binding draft
[I-D.ietf-teep-otrp-over-http] for transport-specific operational
details when that binding is used.”

- This seems like an unusual requirement to demonstrate compliance!
-- I’m surprised that the operator would choose the properties of the transport bindings.
- e.g., Is it possible that “operators MUST ensure the chosen transport provides
adequate confidentiality, integrity, authentication, and replay
protection” could be removed and replaced by a cross-reference to Section 11, or is something more needed to be explained?

### Section 11
Thank you for adding Section 11 in response to that review on “Transport Considerations". This does clarify requirements related to transport protocols and error handling. Although the title word “considerations” might result in these requirements being overlooked whereas this section adds a useful set of requirements.  I suggest the title of this section ought to be changed to indicate that this places requirements on future transport protocol bindings.

[Ballot comment]
Hi Hannes, all,

All my comments in my previous ballot [1] are addressed in [2]. Thank you.

I noticed the following when checking the new version:

# Broken heading: OPS section is a separate section, not a subsection of sec section

OLD:
  10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
    10.1.  Operational Considerations . . . . . . . . . . . . . . .  51

NEW:
  10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
  11.  Operational Considerations . . . . . . . . . . . . . . .  51

# 0 is a reserved/not allowed type value

CURRENT:
  ; message type numbers, in one byte which could take a
  ; number from 0 to 23
  $teep-type /= (0..23)

I would align the CDDL with the intended usage. Having a mention that 0 is reserved and MUST NOT be used would be sufficient.

# Inconsistency

Some text clean-up is needed here as its says contradicting things:

CURRENT (4.6):
  err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message.  Note that error
      codes are restricted to the range (0..23) to permit encoding as
      single-byte CBOR unsigned integers.  Error code values 0, 11-16,
      and 18-22 are currently unassigned and reserved for future use.
      Error code 0 is intentionally reserved to prevent accidental use.

NEW:
  err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message. Error code values 11-16,
      and 18-22 are currently unassigned and reserved for future use.

# Specification Required policy: Missing Guideline for DEs

You have several ranges that are governed by Specification Required policy. That policy involves experts per rfc8126#section-4.6:

  For the Specification Required policy, review and approval by a
  designated expert (see Section 5) is required, and the values and
  their meanings must be documented in a permanent and readily
  available public specification, in sufficient detail so that
  interoperability between independent implementations is possible.
  This policy is the same as Expert Review, with the additional

Some guidance to help DEs perform reviews would be needed here per rfc8126#section-4.5:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.  It is particularly important to lay out what should be
  considered when performing an evaluation and reasons for rejecting a
  request.  It is also a good idea to include, when possible, a sense
  of whether many registrations are expected over time, or if the
  registry is expected to be updated infrequently or in exceptional
  circumstances only.

# Guidance for authors/experts/IANA?

Section 13.6 says:

  Any new cipher suites MUST provide authentication, integrity, and
  SHOULD provide confidentiality protection.

The normative requirements can be moved to the main body of the spec. You formulate it as a guidance for DEs.

Please check “Inappropriate Uses of Key Words” in https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ for the matter.

# Add RFC 8792 to your references as that is needed to unfold the examples.

CURRENT:
CBOR Diagnostic Notation of SUIT Manifest

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

You may add the following at the end of your section 2:

NEW:
  Examples are folded following the conventions in [RFC8792].

# Replace teep-success with success (3 occurrences)

CURRENT:
D.5.1.  CBOR Diagnostic Notation

  / teep-success = /
  [
    / type: / 5 / TEEP-TYPE-teep-success /,
    / options: /
    {
      / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF'
    }
  ]

D.5.2.  CBOR Binary Representation

  82                  # array(2)
      05              # unsigned(5) / TEEP-TYPE-teep-success /
      A1              # map(1)
        14            # unsigned(20) / token: /
        50            # bytes(16)
            A0A1A2A3A4A5A6A7A8A9AAABACADAEAF

# Replace teep-error with error (3 occurrences)


CURRENT:
D.6.1.  CBOR Diagnostic Notation

  / teep-error = /
  [
    / type: / 6 / TEEP-TYPE-teep-error /,
    / options: /
    {
      / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF',
      / err-msg / 12 : "disk-full"
    },
    / err-code: / 17 / ERR_MANIFEST_PROCESSING_FAILED /
  ]

D.6.2.  CBOR binary Representation

  83                  # array(3)
      06              # unsigned(6) / TEEP-TYPE-teep-error /

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-teep-protocol-23&url2=draft-ietf-teep-protocol-24&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/teep/EtIwDcTHKHxr0y8-6xUzAdMY8RQ/

IANA has issues with the new actions added to draft-ietf-teep-protocol after its initial IETF Last Call review:

1) The tables that initialize the new registries repeatedly describe ranges as "(Reserved for future use)", but also assign registration procedures to those ranges. If these values are available for assignment, the string "(Reserved for future use)" needs to be changed to "Unassigned". The RFC 8126 definition of "Reserved" is essentially "not available for assignment." Furthermore, the registration procedures for many of these values is Specification Required, but unless the specification is an IETF Stream RFC, the spec would not be able to release a reserved value.

If the intention is simply to ensure that IANA doesn't automatically assign contiguous values, this can be avoided by telling authors that they can suggest specific values. IANA will generally assign values that documents describe as "suggested" whenever those values are available (designated expert, where applicable, permitting).

Please note that this affects not only the tables in the IANA Considerations section, but also occurrences of "reserved for future use" throughout the document, except where referring to values that are genuinely meant to be reserved.

2) Please add guidance for the designated experts who are going to review requests for registration in the Specification Required range. See RFC 8126, Section 5.3 for advice. (If the same guidance will apply to all of the registries, one way to approach this would be to add a single subsection to the end of the section.)

3) We also need to request a terminology change.

In Section 13.2:

OLD: IANA is requested to create a new registry titled "TEEP Message
  Types" within the TEEP registry.

NEW: IANA is requested to create a new registry titled "TEEP Message
  Types" within a new "Trusted Execution Environment Provisioning (TEEP)" registry group.

In Sections 13.3-13.7:

OLD: within the TEEP registry

NEW: within the TEEP registry group

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-teep-protocol-24
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-teep-protocol-24.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/

## Thanks to the Reviewers

Many thanks to Scott Hollenbeck for the ARTART review, and thanks to the
authors for addressing his comment.

## Comments

I have no objection to the publication of this document as an RFC.

[Ballot discuss]
Hi Hannes, Mingliang, Dave W., Dave T., and Akira,

Thank you for this well-written specification. Special thanks for the detailed Operational section.

Thanks also to Luigi Iannone for the OPSDIR and for the authors for engaging and addressing the comments.

Please find below some few DISCUSS points:

# CDDL is normative

CURRENT:
  The TEEP protocol messages are described in CDDL format [RFC8610]

8610 is required to understand the format of TEEP messages.

# Conceptual APIs is normative

CURRENT:
  Behavior is specified in terms of the conceptual APIs defined in
  Section 6.2.1 of [RFC9397].

[Ballot comment]
# THANK YOU for providing section 3

It is really useful. I would suggest that this section also covers the following:

## Indicate that TEEP is transport-agonstic.

## Clarify whether one or multiple TAMs are supported.

Some of the text seems to assume there is a single manager:

CURRENT:

4.4.  Update Message

  The Update message is used by the TAM
                                ^^^^
## Add a mention about the unsolicited mode. This would basically echo this part in Section 4.3:

CURRENT:
  As discussed in
  Section 7.2, it can also be sent unsolicited if the contents of the
  QueryRequest are already known and do not vary per message.

# Messages pattern

CURRENT:
  $teep-message-type /= query-request
  $teep-message-type /= query-response
  $teep-message-type /= update
  $teep-message-type /= teep-success
  $teep-message-type /= teep-error

any reason why the same pattern is not followed? For example, why some are prefixed with “teep-“?

# contiguous types

CURRENT:
  TEEP-TYPE-query-request = 1
  TEEP-TYPE-query-response = 2
  TEEP-TYPE-update = 3
  TEEP-TYPE-teep-success = 5
  TEEP-TYPE-teep-error = 6

any reason why contiguous types are not used here? Why 4 is not used?

Having an explanation early in the document would be helpful.

(I see that it is marked as reserved in the IANA section)

## the same comments applies for other parts,

CURRENT:
                +--------------------------------+-------+
                | supported-suit-cose-profiles  | 4    |
                +--------------------------------+-------+
                | selected-version              | 6    |
                +--------------------------------+-------+
                | attestation-payload            | 7    |
                +--------------------------------+-------+


# Repetitive text

CURRENT:
  The complete CDDL
  structure is shown in Appendix C.

You may mention this once, instead of repeating it for each snippet.

# TEEP version

CURRENT:
      The selected-version parameter indicates the TEEP protocol version
      selected by the TEEP Agent. 

Is there any value in tracking TEEP protocol version in a registry?

# is there any impact on the interoperability when this part is followed?

CURRENT:
  Use of any other format, such as a widely implemented
  format for a specific processor vendor, is permitted when
  standardized EAT support is not available or when proprietary formats
  provide essential functionality, but this increases the complexity of
  the TAM by requiring it to understand the format for each such format
  rather than only the common EAT format and is not recommended for
  interoperable deployments.

# reserved values

CURRENT:
  update = [
    type: TEEP-TYPE-update,
    options: {
      ? token => bstr .size (8..64),
      ? unneeded-manifest-list => [ + SUIT_Component_Identifier ],
      ? manifest-list => [ + bstr .cbor SUIT_Envelope ],
      ? attestation-payload-format => text,
      ? attestation-payload => bstr,
      ? err-code => (0..23),    <===================
      ? err-msg => text .size (1..128),
      ? err-lang => text .size (1..35),
      * $$update-extensions,
      * $$teep-option-extensions
    }
  ]

Isn’t 0 reserved and must not be used?

# Language

CURRENT:
      When present,
      implementations MUST use the language tag to aid human operators
      in interpreting diagnostic text.  The err-msg field SHOULD be
      formatted in the language indicated by this tag.

What is the behavior if a language is not supported?

# Operational Considerations as separate section

OLD:
  10.1.  Operational Considerations

NEW:
  11.  Operational Considerations

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-teep-protocol-21. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the application namespace of the Media Types registry located at:

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

a single, new Media Type will be registered as follows:

Name: teep+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teep-protocol@ietf.org, kondtir@gmail.com, paul.wouters@aiven.io, teep-chairs@ietf.org, teep@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Trusted Execution Environment Provisioning (TEEP) Protocol) to Proposed Standard


The IESG has received a request from the Trusted Execution Environment
Provisioning WG (teep) to consider the following document: - 'Trusted
Execution Environment Provisioning (TEEP) Protocol'
  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-20. 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 specifies a protocol that installs, updates, and
  deletes Trusted Components in a device with a Trusted Execution
  Environment (TEE).  This specification defines an interoperable
  protocol for managing the lifecycle of Trusted Components.




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



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

Title: Trusted Execution Environment Provisioning (TEEP) Protocol

Current Version: https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-15

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

The draft was adopted in Dec, 2017 with good WG support for adoption. It has been thoroughly reviewed by working group members. The authors have given updates on progress of the draft during all of the WG meetings. A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. Further, there has been active participation in IETF Hackathon activities from WG members to implement, test and interop TEEP protocol.  The authors of this document have extensive experience with the TEE technologies and implementations.

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

No, there was no controversy about any points in the draft.

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

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict.

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

Multiple open source code repositories of the TEEP protocol is available and are listed in the "Additional resources" Section of https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/. The protocol was implemented and interop was done during IETF hackathons to identify and fix issues. IETF hackathon reports were presented in the WG meetings.

## 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? If yes, describe which
  reviews took place.

The TEEP protocol uses CBOR and relies on COSE for security. It leverages the work in SUIT (SUIT manifest format is used) and RATS (EAT format is used) WGs. The draft has been reviewed by members actively contributing to these working groups.


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.

No.

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

No.

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.

Yes, CBOR's CDDL validation was done for every commit (see https://github.com/ietf-teep/teep-protocol)

## 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, it is ready to be handed off to the responsible AD.

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

This draft requires reviews from SECDIR and IOTDIR representatives.


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

Proposed Standard as indicated on the title page header and in the datatracker.

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

All authors and contributors confirmed that they are not aware of any IPR related to this draft.

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.

The total number of authors of this specification are 5.

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

IDnits reported issues and it will be fixed in the next revision.

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

None.

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

None.

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

None.

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?

a) draft-ietf-rats-eat: submitted to IESG ---> published as RFC
b) draft-ietf-suit-manifest: submitted to IESG --> in RFC Editor's Queue
c) draft-ietf-suit-trust-domains: WGLC done, revised I-D needed --> in IESG processing.
d) draft-ietf-suit-mti: getting ready for WGLC --> in IETF LC
e) draft-ietf-suit-report: getting ready for WGLC --> in IESG processing.

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, publication of this document will not change the status of any existing
RFCs.

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

It requests IANA to assign a media type for "application/teep+cbor".


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.

Not applicable

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

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

Title: Trusted Execution Environment Provisioning (TEEP) Protocol

Current Version: https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-15

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

The draft was adopted in Dec, 2017 with good WG support for adoption. It has been thoroughly reviewed by working group members. The authors have given updates on progress of the draft during all of the WG meetings. A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. Further, there has been active participation in IETF Hackathon activities from WG members to implement, test and interop TEEP protocol.  The authors of this document have extensive experience with the TEE technologies and implementations.

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

No, there was no controversy about any points in the draft.

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

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict.

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

Multiple open source code repositories of the TEEP protocol is available and are listed in the "Additional resources" Section of https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/. The protocol was implemented and interop was done during IETF hackathons to identify and fix issues. IETF hackathon reports were presented in the WG meetings.

## 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? If yes, describe which
  reviews took place.

The TEEP protocol uses CBOR and relies on COSE for security. It leverages the work in SUIT (SUIT manifest format is used) and RATS (EAT format is used) WGs. The draft has been reviewed by members actively contributing to these working groups.


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.

No.

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

No.

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.

Yes, CBOR's CDDL validation was done for every commit (see https://github.com/ietf-teep/teep-protocol)

## 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, it is ready to be handed off to the responsible AD.

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

This draft requires reviews from SECDIR and IOTDIR representatives.


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

Proposed Standard as indicated on the title page header and in the datatracker.

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

All authors and contributors confirmed that they are not aware of any IPR related to this draft.

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.

The total number of authors of this specification are 5.

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

IDnits reported issues and it will be fixed in the next revision.

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

None.

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

None.

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

None.

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?

a) draft-ietf-rats-eat: submitted to IESG ---> published as RFC
b) draft-ietf-suit-manifest: submitted to IESG --> in RFC Editor's Queue
c) draft-ietf-suit-trust-domains: WGLC done, revised I-D needed --> in IESG processing.
d) draft-ietf-suit-mti: getting ready for WGLC --> in IETF LC
e) draft-ietf-suit-report: getting ready for WGLC --> in IESG processing.

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, publication of this document will not change the status of any existing
RFCs.

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

It requests IANA to assign a media type for "application/teep+cbor".


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.

Not applicable

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

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

Changed document external resources from:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep (C Implementation: TEEP protocol and HTTP transport for TEEP)
related_implementations https://github.com/ko-isobe/tamproto/ (TAM server functionality)
related_implementations https://github.com/mcd500/ta-ref
related_implementations https://github.com/mcd500/teep-device
related_implementations https://github.com/yuichitk/libteep/ (C Implementation for encoding/decoding TEEP Protocol messages)
webpage https://github.com/ietf-teep/teep-protocol/wiki

to:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep (C Implementation: TEEP protocol and HTTP transport for TEEP)
related_implementations https://github.com/ko-isobe/tamproto/ (TAM server functionality)
related_implementations https://github.com/mcd500/ta-ref (Trusted Application Reference)
related_implementations https://github.com/mcd500/teep-device (TEEP Agent and sample TA)
related_implementations https://github.com/yuichitk/libteep/ (C Implementation for encoding/decoding TEEP Protocol messages)
webpage https://github.com/ietf-teep/teep-protocol/wiki

Changed document external resources from:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep (C Implementation: TEEP protocol and HTTP transport for TEEP)
related_implementations https://github.com/ko-isobe/tamproto/ (TAM server functionality)
related_implementations https://github.com/yuichitk/libteep/ (C Implementation for encoding/decoding TEEP Protocol messages)

to:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep (C Implementation: TEEP protocol and HTTP transport for TEEP)
related_implementations https://github.com/ko-isobe/tamproto/ (TAM server functionality)
related_implementations https://github.com/mcd500/ta-ref
related_implementations https://github.com/mcd500/teep-device
related_implementations https://github.com/yuichitk/libteep/ (C Implementation for encoding/decoding TEEP Protocol messages)
webpage https://github.com/ietf-teep/teep-protocol/wiki

Title: Trusted Execution Environment Provisioning (TEEP) Protocol

Current Version: https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-15

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

The draft was adopted in Dec, 2017 with good WG support for adoption. It has been thoroughly reviewed by working group members. The authors have given updates on progress of the draft during all of the WG meetings. A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. Further, there has been active participation in IETF Hackathon activities from WG members to implement, test and interop TEEP protocol.  The authors of this document have extensive experience with the TEE technologies and implementations.

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

No, there was no controversy about any points in the draft.

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

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict.

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

Multiple open source code repositories of the TEEP protocol is available and are listed in the "Additional resources" Section of https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/. The protocol was implemented and interop was done during IETF hackathons to identify and fix issues. IETF hackathon reports were presented in the WG meetings.

## 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? If yes, describe which
  reviews took place.

The TEEP protocol uses CBOR and relies on COSE for security. It leverages the work in SUIT (SUIT manifest format is used) and RATS (EAT format is used) WGs. The draft has been reviewed by members actively contributing to these working groups.


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.

No.

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

No.

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.

Yes, CBOR's CDDL validation was done for every commit (see https://github.com/ietf-teep/teep-protocol)

## 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, it is ready to be handed off to the responsible AD.

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

This draft requires reviews from SECDIR and IOTDIR representatives.


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

Proposed Standard as indicated on the title page header and in the datatracker.

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

All authors and contributors confirmed that they are not aware of any IPR related to this draft.

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.

The total number of authors of this specification are 5.

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

IDnits reported issues and it will be fixed in the next revision.

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

None.

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

None.

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

None.

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?

a) draft-ietf-rats-eat: submitted to IESG
b) draft-ietf-suit-manifest: submitted to IESG
c) draft-ietf-suit-trust-domains: WGLC done, revised I-D needed
d) draft-ietf-suit-mti: getting ready for WGLC
e) draft-ietf-suit-report: getting ready for WGLC

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, publication of this document will not change the status of any existing
RFCs.

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

It requests IANA to assign a media type for "application/teep+cbor".


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.

Not applicable

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

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

Title: Trusted Execution Environment Provisioning (TEEP) Protocol

Current Version: https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-15

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

The draft was adopted in Dec, 2017 with good WG support for adoption. It has been thoroughly reviewed by working group members. The authors have given updates on progress of the draft during all of the WG meetings. A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. Further, there has been active participation in IETF Hackathon activities from WG members to implement, test and interop TEEP protocol.  The authors of this document have extensive experience with the TEE technologies and implementations.

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

No, there was no controversy about any points in the draft.

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

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict.

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

Multiple open source code repositories of the TEEP protocol is available and are listed in the "Additional resources" Section of https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/. The protocol was implemented and interop was done during IETF hackathons to identify and fix issues. IETF hackathon reports were presented in the WG meetings.

## 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? If yes, describe which
  reviews took place.

The TEEP protocol uses CBOR and relies on COSE for security. It leverages the work in SUIT (SUIT manifest format is used) and RATS (EAT format is used) WGs. The draft has been reviewed by members actively contributing to these working groups.


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.

No.

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

No.

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.

Yes, CBOR's CDDL validation was done for every commit (see https://github.com/ietf-teep/teep-protocol)

## 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, it is ready to be handed off to the responsible AD.

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

This draft requires reviews from SECDIR and IOTDIR representatives.


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

Proposed Standard as indicated on the title page header and in the datatracker.

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

All authors and contributors confirmed that they are not aware of any IPR related to this draft.

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.

The total number of authors of this specification are 5.

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

IDnits reported issues and it will be fixed in the next revision.

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

None.

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

None.

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

None.

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?

a)ietf-rats-eat: ready for submit to ISEG for review
b)suit-manifest : WGLC is complete, AD review
c)suit-mti : WG document
d)suit-report : WG document
e)suit-trust-domains : In WGLC

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, publication of this document will not change the status of any existing
RFCs.

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

It requests IANA to assign a media type for "application/teep+cbor".


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.

Not applicable

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

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

Changed document external resources from:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep

to:

github_repo https://github.com/ietf-teep/teep-protocol
related_implementations https://github.com/dthaler/teep (C Implementation: TEEP protocol and HTTP transport for TEEP)
related_implementations https://github.com/ko-isobe/tamproto/ (TAM server functionality)
related_implementations https://github.com/yuichitk/libteep/ (C Implementation for encoding/decoding TEEP Protocol messages)