Reviewer: Russ Housley Review result: Almost Ready 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
