I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-teep-otrp-over-http-13
Reviewer: Russ Housley
Review Date: 2022-03-28
IETF LC End Date: 2022-04-07
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns:

Section 1 says:

   This document specifies the middle layer (TEEP-over-HTTP), whereas
   the top layer (TEEP) is specified in [I-D.ietf-teep-protocol].

I think this should be expanded to provide a reference for the HTTP
layer as well.  Something like:

   TEEP implementations MUST support HTTP [RFC9110].
   
I realize that this document references I-D.ietf-httpbis-semantics,
which talks about HTTP/1.0, HTTP/1.1, HTTP/2, and HTTP/3, and it says:

   All three major versions of HTTP rely on the semantics defined by
   this document.  They have not obsoleted each other because each one
   has specific benefits and limitations depending on the context of
   use.  Implementations are expected to choose the most appropriate
   transport and messaging syntax for their particular context.

Therefore, it might appropriate for this document to select a version
of HTTP for interoperability.


Minor Concerns:

The Abstract says: "An implementation of this document can (if desired)
run outside of any TEE, but interacts with a TEEP implementation that runs
inside a TEE."  This is a little bit confusing.  I think that it is trying
to say that one oc the TEEP implementations must be running inside the TEE
that is being managed by the TAM, but the TAM side on the protocol does
not need to be implemented in a separate TEE of its own.  I hope that I
got that right.  The most straightforward clarification might be to add
a sentence about the client side of the protocol, TEEP "Agent", runs in the
TEE that is being managed by the TAM.  Please clarify.

Section 8 should be expanded.  In Section 4, the document says:

   However, there may be constrained nodes where code space is an issue.
   [RFC7925] provides TLS profiles that can be used in many constrained
   nodes, but in rare cases the most constrained nodes might need to use
   HTTP without a TLS stack, relying on the end-to-end security provided
   by the TEEP protocol.

Section 8 ought to discuss this a bit more.  That is, when TLS is not
used, what are the additional security considerations?


Nits:

Section 1, s/A fuller discussion of/A more complete discussion of/


IDnits reports:

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.ietf-httpbis-semantics' 

This document will be published on the standards track, so it will not
be a downref.