[secdir] Secdir last call review of draft-ietf-teep-otrp-over-http-14

Stefan Santesson via Datatracker <noreply@ietf.org> Mon, 17 October 2022 22:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD05C15258E; Mon, 17 Oct 2022 15:05:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stefan Santesson via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-teep-otrp-over-http.all@ietf.org, last-call@ietf.org, teep@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.18.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166604435575.23410.12533981427414843723@ietfa.amsl.com>
Reply-To: Stefan Santesson <stefan@aaa-sec.com>
Date: Mon, 17 Oct 2022 15:05:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MzG3-vpyMzuyG0-fRAZf8ul6wGo>
Subject: [secdir] Secdir last call review of draft-ietf-teep-otrp-over-http-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2022 22:05:55 -0000

Reviewer: Stefan Santesson
Review result: Ready

I have dropped this review as it has been overdue for quite some time. But
since it still appears on my review-list, I took a look at it now in case this
is of any interest.

I have little knowledge about TEEP and the rationale behind its design
decisions. I trust that the author has that part figured out. My interest was
primarily in the requirements for HTTPS versus HTTP and how that was motivated.

A rather interesting observation in this regard was the attempt to "spice" the
requirement language of the specification. See section 4:

"It is strongly RECOMMENDED that implementations use HTTPS."

This brings my thought to other interesting alternatives to spice requirements
as defined in RFC 6919 like "OUGHT TO" ? ;)

But jokes aside, I'm not sure "strongly" is appropriate next to "RECOMMENDED".

But other than that I find no issues with the document.