[dns-privacy] John Scudder's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Thu, 10 March 2022 14:25 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB73A161E; Thu, 10 Mar 2022 06:25:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-dnsoquic@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, brian@innovationslab.net, dns-privacy@ietf.org, brian@innovationslab.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <164692235007.27715.1964541243761693354@ietfa.amsl.com>
Date: Thu, 10 Mar 2022 06:25:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/fzJdI-ILz0l2v6fbdFj5gI6fOsw>
Subject: [dns-privacy] John Scudder's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2022 14:25:50 -0000
John Scudder has entered the following ballot position for draft-ietf-dprive-dnsoquic-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this, I found it clear and easy to read. I have just a couple comments. 1. In §5.2, there is Servers MAY defer processing of a query until the STREAM FIN has been indicated on the stream selected by the client. Servers and clients MAY monitor the number of "dangling" streams for which the expected queries or responses have been received but not the STREAM FIN. Implementations MAY impose a limit on the number of such dangling streams. If limits are encountered, implementations MAY close the connection. Wouldn’t a stream be dangling even if the expected queries and responses hadn’t been received? I.e., isn’t the thing that makes a stream “dangling” simply the lack of a STREAM FIN? 2. In §5.4, Client and servers that send packets over a connection discarded by their peer MAY receive a stateless reset indication. This seems like a misuse of the RFC 2119 MAY. Do you mean "may" or better still, "might" or "could"? If you really mean the 2119 keyword, then a rewrite seems to be in order to put this in terms of the other party being permitted to send the reset.
- [dns-privacy] John Scudder's No Objection on draf… John Scudder via Datatracker
- Re: [dns-privacy] John Scudder's No Objection on … Sara Dickinson
- Re: [dns-privacy] John Scudder's No Objection on … John Scudder