[Last-Call] Artart last call review of draft-ietf-ohai-ohttp-05
Sean Turner via Datatracker <noreply@ietf.org> Tue, 29 November 2022 20:37 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9981CC152597; Tue, 29 Nov 2022 12:37:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Sean Turner via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-ohai-ohttp.all@ietf.org, last-call@ietf.org, ohai@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166975427461.15718.10748282060608790716@ietfa.amsl.com>
Reply-To: Sean Turner <sean+ietf@sn3rd.com>
Date: Tue, 29 Nov 2022 12:37:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/cJMOJi8ezn_4bOsFn30yn_BB2TM>
Subject: [Last-Call] Artart last call review of draft-ietf-ohai-ohttp-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2022 20:37:54 -0000
Reviewer: Sean Turner Review result: Ready with Nits Note I reviewed the -05 version and the editor’s diff to their working draft. Thanks for the well written doc. I really have only two questions and some nits: 1. Is “intercept” the right word in the following text from s3: In order to ensure that Clients do not encapsulate messages that other entities can intercept, the key configuration MUST be authenticated and have integrity protection. I do not usually think of authentication and integrity as a mitigation against interception. Maybe it’s that it just can’t be encrypted it must use AEAD? Or, maybe I missed something. 2. The text in s6.5 about the Client and Oblivious Relay not automatically attempting a retry makes me wonder if this protocol is applicable only to HTTP/2 and HTTP/3, but I know that’s not intended (see HTTP/1.1 examples)? How is a pre-HTTP/2 client supposed to know no processing occurred? Nits follow, but are in a PR (https://github.com/ietf-wg-ohai/oblivious-http/pull/221): s2: s/A Oblivious/An Oblivious s4.3: s/request request/request, request, s4.4:s/response response/response, response, s4.4, step 1: s/secret secret/secret, secret, s4.4, step 3: s/response_nonce/response_nonce. s4.4, step 5: s/nonce nonce/nonce, nonce, s5: s/For the request the/For the request, the s6.2: s/HTTP, a Oblivious/HTTP, an Oblivious s6.2:s/though it assumed to/though it is assumed s6.3: s:/ such those/such as those s7: s/critical prevent/critical to prevent Hobby Horse: When are HTTP examples going to switch to H2 or H3?
- [Last-Call] Artart last call review of draft-ietf… Sean Turner via Datatracker
- Re: [Last-Call] [Ohai] Artart last call review of… Martin Thomson