Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-19

[Ballot comment]
Thanks for working on this specification. It was a good read for me. I will skip the nits but noted that "consensus boiler plate" entry is missing in the datatracker.

[Ballot comment]
My colleagues already did a pretty thorough job.  I've only a few things to add.

The shepherd writeup is over a year old.  It lists Ben Kaduk as the responsible AD.

In Section 4.1, it says "Figure 1 shows the main components in a typical device with an REE and a TEE."  Where's the REE?  Is it the "Device"?

"SGX" should be expanded on first use (Section 4.1), but it's actually expanded in Section 4.4.1.

Nits:

Use of capitalization is inconsistent.  For instance, "Device User" is capitalized when defined, but never again; meanwhile, "Personalization Data" is always capitalized.

Section 1:

* "TEEs use hardware enforcement combined with software protection to secure TAs and its data." -- s/its/their/

Section 2:

* "Device User" is never used outside of the "Terminology" section; is it needed?

[Ballot comment]
# Internet AD comments for {draft-ietf-teep-architecture-18}
CC @ekline

## Comments

* Thanks very much to Ines Robles for the IoT Directorate review.

  Please review the feedback at:

  https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/

[Ballot comment]
Thank you to Ben Schwartz for the SECDIR review. Please review his feedback.

** Section 1.
  The
  danger  of attacks on a system increases as the sensitivity of the
  applications or data on the device increases.  As an example,
  exposure of emails from a mail client is likely to be of concern to
  its owner, but a compromise of a banking application raises even
  greater concerns.

Based on the example, is it the “danger of attacks” or the “consequences of attacks”?

** Section 1. There are two different threat models implicitly described in this section.  The first paragraph seems outline the risk of multiple applications on the same devices and the complexity of those applications.  The fourth paragraph describes the threat of threat actors with physical access.  Are we talking about both?

** Section 3.1.  Is a “trusted user interface” something that needs to be defined?  Is it an example of a trusted TA?

** Section 3.3.
  A TEE can be the best way
  to implement such IoT security functions.

This seems like a strong but unsupported claim.  Consider something weaker.

** Section 4.4.
  Implementations must support encryption to
  preserve the confidentiality of such Personalization Data, which may
  potentially contain sensitive data.  Implementations must also
  support mechanisms for integrity protection of such Personalization
  Data. 

Please clarify what it means to “support encryption.”  Is this saying that all personalization data at rest must be encrypted?  No personalization data can be sent in the clear?

** Section 6.2
A TEEP Broker abstracts the message exchanges with a TEE in a device.

What does it mean for the broker to “abstract” the message exchange?

** Section 7.  What is the relationship between the attestation process in Figure 6 and the conceptual message flow described in 6.2.1?

** Section 7.

  Different Verifiers may require different degrees of
  confidence in attestation proofs and not all attestations are
  acceptable to every verifier

Why is the first instance of “verifiers” a proper noun (capitalized) but the second is not?

** Section 9.  This section notes a few instances where a TEE should detect that something potentially suspect is happening.  How, if at all, should logging of this phenomenon occur?  How would someone managing devices become aware of it or be notified?

** Section 9.  From the SECDIR review:
==[ snip ]==
Nothing here seems to discuss attacks on the TEE's properties, and the
post-compromise implications of those attacks.  For example, if all instances
of a TA share a secret key, used for decrypting the Personalization Data, then
a single successful attack on a TEE is sufficient to decrypt all
Personalization Data (previous and future).  Given the prevalence of such
attacks (especially via hardware fault injection), it seems likely to be worth
mentioning. [1]
==[ snip ]==

** Section 9.1.  In the spirit of inclusive language, consider if there is an alternative term for “man-in-the-middle”.

** Section 9.1
  While a TEEP Broker broker can in effect make suggestions, it cannot
  decide or enforce what runs where. 

-- Editorial. s/Broker broker/Broker/

-- What suggestions can a Broker make?  Per Section 6.1, I thought the Broker only relayed messages between the Agent and the TAM.

** Section 9.3

  We have
  already seen examples of attacks on the public Internet with billions
  of compromised devices being used to mount DDoS attacks

Can a reference be provided for a single DDoS having billions of compromised devices as sources.

** Section 9.3.

  A compromised REE might also request initiating the full flow of
  installation of Trusted Components that are not necessary. 

With this technique, could a compromised RRE fill up all of the secure storage of a TEE preventing future legitimate installations from occurring?

** Section 9.7

  A TAM certificate usually has a moderate
  lifetime of 2 to 5 years

Is this a recommendation or an observation?  If the former, what is the basis of these numbers?

** Typos
-- Section 4.1.  Typo. s/Administators/Administrators/

-- Section 6. Typo. s/.././

[Ballot comment]
I have very little to add, other than noting that I find Use-Case and Architecture documents to be really helpful.
They help "set the stage" when reading a new set of document, or deploying a new technology. Thank you!

[Ballot comment]
# GEN AD review of draft-ietf-teep-architecture-18

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/_PQLgwbAxaVsfWgfg62QZHYYlYs).

## Comments

### Unclear consensus

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document. The shepherd writeup makes it pretty
clear that it should, so please change the datatracker metadata for the
document?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`
* Terms `she` and `he`; alternatives might be `they`, `them`, `their`

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

### Typos

#### Section 4.1, paragraph 4
```
-      Administators may elect to use a TAM for remote administration of
+      Administrators may elect to use a TAM for remote administration of
+              +
```

#### Section 4.1, paragraph 5
```
-      Trusted Component Signers or Device Administators to use the TAM's
+      Trusted Component Signers or Device Administrators to use the TAM's
+                                                  +
```

#### Section 4.4.2, paragraph 1
```
-    a specific Untrused Application process lifetime as occurs in SGX.  A
+    a specific Untrusted Application process lifetime as occurs in SGX.  A
+                    +
```

#### Section 4.5, paragraph 8
```
-    via a TEEP Broker that faciliates communications between the TAM and
+    via a TEEP Broker that facilitates communications between the TAM and
+                                +
```

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

### Grammar/style

#### Section 2, paragraph 8
```
ust resist modification against unauthorized insertion, deletion, and modifi
                                ^^^^^^^^^^^^
```
Do not mix variants of the same word ("unauthorized" and "unauthorised") within
a single text.

#### Section 4.5, paragraph 9
```
ed further in Section 5.3 below. Typically the same key TEE pair is used for
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 6.1, paragraph 1
```
. ProcessTeepMessage: A message arriving on an existing TEEP session, to be d
                                ^^^^^^^^^^^
```
The usual preposition after "arriving" is "at", not "on". Did you mean
"arriving at"?

#### Section 7, paragraph 1
```
s, from trusted app updates for smart phones and tablets to updates of code
                                ^^^^^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 9.1, paragraph 3
```
AM certificates might get compromised or its certificate might expire, or a T
                                    ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 9.1, paragraph 4
```
EE certificates might get compromised or its certificate might expire, or a T
                                    ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 9.3, paragraph 1
```
oked by a timer or other event. Furthermore the policy in the Verifier in an
                                ^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Furthermore".

#### Section 9.3, paragraph 3
```
certificates are expected to be long lived, longer than the lifetime of a d
                                ^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## Notes

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

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

[Ballot comment]

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

Thank you for the work put into this document. I really like the approach (except perhaps the role of TEEP broker).

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

Please note that Ines Robles (iot dir) and Bob Halley (int dir) have also reviewed the I-D at my request (thank you both !). I would appreciate it if you considered their reviews as mine (including replying by email to their reviews):

* https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/ (esp for her point about RFC 7228 classification)
* https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-intdir-telechat-halley-2022-08-27/ (esp for his point about section 4.1, thanks Ming for your reply)

Special thanks to Tiru Reddy for the *one-year old* shepherd's write-up including the WG consensus but missing the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Role of TEEP Broker

After reading the I-D, I am still a little unclear about the role of the TEEP Broker ? Is it simple a store/forward cache ? I.e., it does not authenticate to any party and does not have any access to any message? If so, it would be nice to say so early in the text (before section 5 when my own penny dropped) and perhaps rename it in 'TEEP relay'.

### Section 1
```
  In a system with multiple TEEs, this also means
  that code in one TEE cannot be read or tampered with by code in
  another TEE.
```
Should this rather be `code and data in one TEE` ?

To be honest, this is the first time I read 'Rich Execution Environment'; should there be some explanations (shorter than the one in the terminology section)? How different is it from the 'commodity operating system' (used in the paragraph above).

### Section 2 physical only ?

`Device: A physical piece of hardware`... I would have guessed that a TEE could exist in a virtual machine provided that the hypervisor offers the same 'physical' security as the HW. I.e., TA in the VM could be 'isolated' from other untrusted app in the same VM. See also section 3.4 and the cloud use case.

### Section 2 no TEE definition ?

A lot of terms are nicely and clearly defined, but 'TEE' itself is not defined.

### Section 2 only TA in TEE ?

The definition of 'TA' implies that it runs in a TEE, but are there only TA running in TEE ?

### Section 4.1 TEEP broker is not trusted ?

Should the TEEP broker itself run in a TEE ? Of course, this is chicken and egg...

### Section 4.1 CA

Nothing dramatic, but the role of a CA is explained in the text while there is no CA in fig 1

### Section 4.4.1 reference

Should there be an informative reference about SGX ?

### Section 4.5 wrong direction ?

Is the arrow (step 4) in the wrong direction as this is up to the TEEP broker to contact the TAM per previous text? or add a similar text as in step 3.

### Section 5.4 and constrained devices

As PKI cert chains can be very long, should there be some text about constrained devices/networks where several kBytes are too many ? Even if only to say 'TEEP is not usable on constrained networks/devices' ?

### Section 9.3

While I do not contest that REE can be compromised, I think that claiming `billions of compromised devices` is too many and should require a reference.

### Section trusting time

As PKI relies on correct time information and as some devices relies on NTP, GSM, GNSS, ... time information and as those can be spoofed, should there be a sub-section on time attack ? (this would be a DoS or allowing the use of an old - compromised - TA / trust anchor).


## Notes

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

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

[Ballot comment]

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

Thank you for the work put into this document. I really like the approach (except perhaps the role of TEEP broker).

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

Please note that Ines Robles (iot dir) and Bob Halley (int dir) have also reviewed the I-D at my request (thank you both !). I would appreciate it if you considered their reviews as mine (including replying by email to their reviews):

* https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/ (esp for her point about RFC 7228 classification)
* https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-intdir-telechat-halley-2022-08-27/ (esp for his point about section 4.1, thanks Ming for your reply)

Special thanks to Tiru Reddy for the *one-year old* shepherd's write-up including the WG consensus but missing the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Role of TEEP Broker

After reading the I-D, I am still a little unclear about the role of the TEEP Broker ? Is it simple a store/forward cache ? I.e., it does not authenticate to any party and does not have any access to any message? If so, it would be nice to say so early in the text (before section 5 when my own penny dropped) and perhaps rename it in 'TEEP relay'.

### Section 1
```
  In a system with multiple TEEs, this also means
  that code in one TEE cannot be read or tampered with by code in
  another TEE.
```
Should this rather be `code and data in one TEE` ?

To be honest, this is the first time I read 'Rich Execution Environment'; should there be some explanations (shorter than the one in the terminology section)? How different is it from the 'commodity operating system' (used in the paragraph above).

### Section 2 physical only ?

`Device: A physical piece of hardware`... I would have guessed that a TEE could exist in a virtual machine provided that the hypervisor offers the same 'physical' security as the HW. I.e., TA in the VM could be 'isolated' from other untrusted app in the same VM. See also section 3.4 and the cloud use case.

### Section 2 no TEE definition ?

A lot of terms are nicely and clearly defined, but 'TEE' itself is not defined.

### Section 2 only TA in TEE ?

The definition of 'TA' implies that it runs in a TEE, but are there only TA running in TEE ?

### Section 4.1 TEEP broker is not trusted ?

Should the TEEP broker itself run in a TEE ? Of course, this is chicken and egg...

### Section 4.1 CA

Nothing dramatic, but the role of a CA is explained in the text while there is no CA in fig 1

### Section 4.4.1 reference

Should there be an informative reference about SGX ?

### Section 4.5 wrong direction ?

Is the arrow (step 4) in the wrong direction as this is up to the TEEP broker to contact the TAM per previous text? or add a similar text as in step 3.

### Section 5.4 and constrained devices

As PKI cert chains can be very long, should there be some text about constrained devices/networks where several kBytes are too many ? Even if only to say 'TEEP is not usable on constrained networks/devices' ?

### Section 9.3

While I do not contest that REE can be compromised, I think that claiming `billions of compromised devices` is too many and should require a reference.

### Section trusting time

As PKI relies on correct time information and as some devices relies on NTP, GSM, GNSS, ... time information and as those can be spoofed, should there be a sub-section on time attack ? (this would be a DoS or allowing the use of an old - compromised - TA / trust anchor).

[Ballot comment]
Hi,

Thanks for this document, I found it pretty easy to read.

Minor level comments:

(1) p 17, sec 4.5.  Entity Relations

  At step 3, a user will go to an Application Store to download the
  Untrusted Application (where the arrow indicates the direction of
  data transfer).

I note that this diagram doesn't actually include the user, possibly consider changing "3. Install to 3. User Install"


(2) p 17, sec 4.5.  Entity Relations

  At step 4, since the Untrusted Application depends on the TA,
  installing the Untrusted Application will trigger TA installation via
  communication with a TAM.  The TEEP Agent will interact with the TAM
  via a TEEP Broker that faciliates communications between the TAM and
  the TEEP Agent.

I found this quite unclear from the diagram, it looked like the messaging is initiated from the TAM to the Device with the TEE.  I also found the time flow in this diagram to be somewhat unclear, since normally time flows downwards with sequence diagrams, but I wasn't convinced that was the case here.  E.g. TA -- 2b is lower than 3. Install.


(3) p 21, sec 5.4.  Scalability

  factory.  Likewise, new TAMs can join the ecosystem, providing they
  are issued a TAM certificate that chains to an existing root whereby
  existing TEEs will be allowed to be personalized by the TAM without
  requiring changes to the TEE itself.

It isn't clear to me what is meant by "personalized by the TAM".


(4) p 21, sec 5.5.  Message Security

  These messages are signed end-to-end between a TEEP Agent and a TAM.
  Confidentiality is provided by encrypting sensitive payloads (such as
  Personalization Data and attestation evidence), rather than
  encrypting the messages themselves.  Using encrypted payloads is
  important to ensure that only the targeted device TEE or TAM is able
  to decrypt and view the actual content.

It's not obvious to me why you would only encrypt the payload and not the messages themselves.  Is this so that 'routing information' is readily available or something else?


(5) p 23, sec 6.2.1.  TEEP Broker APIs

  The following conceptual APIs exist from a TEEP Broker to a TEEP
  Agent:

I'm slightly surprised that the conceptual TEEP Broker APIs are contained in this document when the other equivalent TEEP APIs are not.


(6) p 24, sec 6.2.2.  TEEP Broker Distribution

  The Broker installation is commonly carried out at OEM time.  A user
  can dynamically download and install a Broker on-demand.

It is unclear to me what is meant by "OEM time"?


(7) p 27, sec 9.  Security Considerations

I note that there is no security considerations for a compromised TEE.  Should this be considered, or is it the case that TEEs cannot be compromised?  Similarly, is a compromised TA something that should be considered here?



Nit level comments:

(8) p 3, sec 1.  Introduction

  *  An installer of an Untrusted Application that depends on a given
      TA wants to request installation of that TA in the device's TEE so
      that the Untrusted Application can complete, but the TEE needs to

Should this be "so that the installation of the Untrusted Application can complete?


(9) p 16, sec 4.4.2.  Example: Application Delivery Mechanisms in Arm TrustZone

  A trusted OS running in the TEE (e.g., OP-TEE) that supports loading
  and verifying signed TAs from an untrusted filesystem can, like SGX,
  use classic file distribution mechanisms.

I suggest expanding OP-TEE, it wasn't obvious to me what this was.

Thanks,
Rob

[Ballot comment]
Hi,

Thanks for this document, I found it pretty easy to read.

Minor level comments:

(1) p 17, sec 4.5.  Entity Relations

  At step 3, a user will go to an Application Store to download the
  Untrusted Application (where the arrow indicates the direction of
  data transfer).

I note that this diagram doesn't actually include the user, possibly consider changing "3. Install to 3. User Install"


(2) p 17, sec 4.5.  Entity Relations

  At step 4, since the Untrusted Application depends on the TA,
  installing the Untrusted Application will trigger TA installation via
  communication with a TAM.  The TEEP Agent will interact with the TAM
  via a TEEP Broker that faciliates communications between the TAM and
  the TEEP Agent.

I found this quite unclear from the diagram, it looked like the messaging is initiated from the TAM to the Device with the TEE.  I also found the time flow in this diagram to be somewhat unclear, since normally time flows downwards with sequence diagrams, but I wasn't convinced that was the case here.  E.g. TA -- 2b is lower than 3. Install.


(3) p 21, sec 5.4.  Scalability

  factory.  Likewise, new TAMs can join the ecosystem, providing they
  are issued a TAM certificate that chains to an existing root whereby
  existing TEEs will be allowed to be personalized by the TAM without
  requiring changes to the TEE itself.

It isn't clear to me what is meant by "personalized by the TAM".


(4) p 21, sec 5.5.  Message Security

  These messages are signed end-to-end between a TEEP Agent and a TAM.
  Confidentiality is provided by encrypting sensitive payloads (such as
  Personalization Data and attestation evidence), rather than
  encrypting the messages themselves.  Using encrypted payloads is
  important to ensure that only the targeted device TEE or TAM is able
  to decrypt and view the actual content.

It's not obvious to me why you would only encrypt the payload and not the messages themselves.  Is this so that 'routing information' is readily available or something else?


(5) p 23, sec 6.2.1.  TEEP Broker APIs

  The following conceptual APIs exist from a TEEP Broker to a TEEP
  Agent:

I'm slightly surprised that the conceptual TEEP Broker APIs are contained in this document when the other equivalent TEEP APIs are not.


(6) p 24, sec 6.2.2.  TEEP Broker Distribution

  The Broker installation is commonly carried out at OEM time.  A user
  can dynamically download and install a Broker on-demand.

It is unclear to me what is meant by "OEM time"?


(7) p 27, sec 9.  Security Considerations

I note that there is no security considerations for a compromised TEE.  Should this be considered, or is it the case that TEEs cannot be compromised?  Similarly, is a compromised TA something that should be considered here?



Nit level comments:

(8) p 3, sec 1.  Introduction

  *  An installer of an Untrusted Application that depends on a given
      TA wants to request installation of that TA in the device's TEE so
      that the Untrusted Application can complete, but the TEE needs to

Should this be "so that the installation of the Untrusted Application can complete?


(9) p 16, sec 4.4.2.  Example: Application Delivery Mechanisms in Arm TrustZone

  A trusted OS running in the TEE (e.g., OP-TEE) that supports loading
  and verifying signed TAs from an untrusted filesystem can, like SGX,
  use classic file distribution mechanisms.

I suggest expanding OP-TEE, it wasn't obvious to me what this was.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-teep-architecture-16, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teep-architecture@ietf.org, kaduk@mit.edu, kondtir@gmail.com, teep-chairs@ietf.org, teep@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Trusted Execution Environment Provisioning (TEEP) Architecture) to Informational RFC


The IESG has received a request from the Trusted Execution Environment
Provisioning WG (teep) to consider the following document: - 'Trusted
Execution Environment Provisioning (TEEP) Architecture'
  as Informational RFC

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 2022-04-07. 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


  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.




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



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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.

Working Group Summary:

The draft was adopted in July 2018 with good WG support for adoption.  The draft has been widely discussed and reviewed. The co-authors of this document are from some of the leading vendors in offering TEE and with extensive experience with the related technologies and implementations, they are also the authors of the TEEP Protocol WG draft which guarantees consistency.

Document Quality:

The draft is mature enough after several revisions and there is strong consensus in the WG to pass the WGLC and go to next stage.

Personnel:

  K Tirumaleswar Reddy (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the document and found it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document was a subject of several reviews in the WG and presentations in IETF meetings.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

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

  ** Mingliang Pei -- https://mailarchive.ietf.org/arch/msg/teep/qkfDsxfI9I8GOhhexf0ukaK6Cy0/
  ** Hannes Tschofenig -- https://mailarchive.ietf.org/arch/msg/teep/_S-3-YLStjm7Sf0RSkUhxhOFkvc/
  ** Dave Thaler – https://mailarchive.ietf.org/arch/msg/teep/Ega8haQM5plqI6ycqz8K4jQ_LG4/
  ** David Wheeler – No IPR (DaveW responded to the WG chairs and co-authors of the draft).

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus is solid.

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

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits reported no issues.

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

The draft contains no YANG or XML modules to validate.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references do not exist in this document.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are defined by this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The draft has no IANA actions.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The draft does not define any YANG module.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-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 RFC8342?

The draft contains no YANG or XML modules to validate.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.

Working Group Summary:

The draft was adopted in July 2018 with good WG support for adoption.  The draft has been widely discussed and reviewed. The co-authors of this document are from some of the leading vendors in offering TEE and with extensive experience with the related technologies and implementations, they are also the authors of the TEEP Protocol WG draft which guarantees consistency.

Document Quality:

The draft is mature enough after several revisions and there is strong consensus in the WG to pass the WGLC and go to next stage.

Personnel:

  K Tirumaleswar Reddy (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the document and found it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document was a subject of several reviews in the WG and presentations in IETF meetings.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

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

  ** Mingliang Pei -- https://mailarchive.ietf.org/arch/msg/teep/qkfDsxfI9I8GOhhexf0ukaK6Cy0/
  ** Hannes Tschofenig -- https://mailarchive.ietf.org/arch/msg/teep/_S-3-YLStjm7Sf0RSkUhxhOFkvc/
  ** Dave Thaler – https://mailarchive.ietf.org/arch/msg/teep/Ega8haQM5plqI6ycqz8K4jQ_LG4/
  ** David Wheeler – No IPR (DaveW responded to the WG chairs and co-authors of the draft).

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus is solid.

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

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits reported no issues.

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

The draft contains no YANG or XML modules to validate.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references do not exist in this document.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are defined by this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The draft has no IANA actions.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The draft does not define any YANG module.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-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 RFC8342?

The draft contains no YANG or XML modules to validate.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.

Working Group Summary:

The draft was adopted in July 2018 with good WG support for adoption.  The draft has been widely discussed and reviewed. The co-authors of this document are from some of the leading vendors in offering TEE and with extensive experience with the related technologies and implementations, they are also the authors of the TEEP Protocol WG draft which guarantees consistency.

Document Quality:

The draft is mature enough after several revisions and there is strong consensus in the WG to pass the WGLC and go to next stage.

Personnel:

  K Tirumaleswar Reddy (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the document and found it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document was a subject of several reviews in the WG and presentations in IETF meetings.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

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

  ** Mingliang Pei -- https://mailarchive.ietf.org/arch/msg/teep/qkfDsxfI9I8GOhhexf0ukaK6Cy0/
  ** Hannes Tschofenig -- https://mailarchive.ietf.org/arch/msg/teep/_S-3-YLStjm7Sf0RSkUhxhOFkvc/
  ** Dave Thaler – https://mailarchive.ietf.org/arch/msg/teep/Ega8haQM5plqI6ycqz8K4jQ_LG4/
  ** David Wheeler – No response from him even after several reminder mails.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus is solid.

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

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits reported no issues.

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

The draft contains no YANG or XML modules to validate.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references do not exist in this document.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are defined by this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The draft has no IANA actions.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The draft does not define any YANG module.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-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 RFC8342?

The draft contains no YANG or XML modules to validate.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.

Working Group Summary:

The draft was adopted in July 2018 with good WG support for adoption.  The draft has been widely discussed and reviewed. The co-authors of this document are from some of the leading vendors in offering TEE and with extensive experience with the related technologies and implementations, they are also the authors of the TEEP Protocol WG draft which guarantees consistency.

Document Quality:

The draft is mature enough after several revisions and there is strong consensus in the WG to pass the WGLC and go to next stage.

Personnel:

  K Tirumaleswar Reddy (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the document and found it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document was a subject of several reviews in the WG and presentations in IETF meetings.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

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

  ** Mingliang Pei -- https://mailarchive.ietf.org/arch/msg/teep/qkfDsxfI9I8GOhhexf0ukaK6Cy0/
  ** Hannes Tschofenig -- https://mailarchive.ietf.org/arch/msg/teep/_S-3-YLStjm7Sf0RSkUhxhOFkvc/
  ** Dave Thaler – https://mailarchive.ietf.org/arch/msg/teep/Ega8haQM5plqI6ycqz8K4jQ_LG4/
  ** David Wheeler – TODO

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus is solid.

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

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits reported no issues.

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

The draft contains no YANG or XML modules to validate.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references do not exist in this document.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are defined by this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The draft has no IANA actions.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The draft does not define any YANG module.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-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 RFC8342?

The draft contains no YANG or XML modules to validate.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  A Trusted Execution Environment (TEE) is an environment that enforces
  that any code within that environment cannot be tampered with, and
  that any data used by such code cannot be read or tampered with by
  any code outside that environment.  This architecture document
  motivates the design and standardization of a protocol for managing
  the lifecycle of trusted applications running inside such a TEE.

Working Group Summary:

The draft was adopted in July 2018 with good WG support for adoption.  The draft has been widely discussed and reviewed. The co-authors of this document are from some of the leading vendors in offering TEE and with extensive experience with the related technologies and implementations, they are also the authors of the TEEP Protocol WG draft which guarantees consistency.

Document Quality:

The draft is mature enough after several revisions and there is strong consensus in the WG to pass the WGLC and go to next stage.

Personnel:

  K Tirumaleswar Reddy (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the document and found it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document was a subject of several reviews in the WG and presentations in IETF meetings.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

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

  ** Mingliang Pei -- https://mailarchive.ietf.org/arch/msg/teep/qkfDsxfI9I8GOhhexf0ukaK6Cy0/
  ** Hannes Tschofenig -- https://mailarchive.ietf.org/arch/msg/teep/_S-3-YLStjm7Sf0RSkUhxhOFkvc/
  ** Dave Thaler – https://mailarchive.ietf.org/arch/msg/teep/Ega8haQM5plqI6ycqz8K4jQ_LG4/
  ** David Wheeler – TODO

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus is solid.

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

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits reported no issues other than the Miscellaneous warning listed below:
  ----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but was
    first submitted on or after 10 November 2008.  The disclaimer is usually
    necessary only for documents that revise or obsolete older RFCs, and that
    take significant amounts of text from those RFCs.  If you can contact all
    authors of the source material and they are willing to grant the BCP78
    rights to the IETF Trust, you can and should remove the disclaimer.
    Otherwise, the disclaimer is needed and you can ignore this comment.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

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

The draft contains no YANG or XML modules to validate.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references do not exist in this document.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are defined by this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The draft has no IANA actions.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The draft does not define any YANG module.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-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 RFC8342?

The draft contains no YANG or XML modules to validate.