Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Lars Eggert <lars@eggert.org> Tue, 26 October 2021 11:37 UTC
Return-Path: <lars@eggert.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F853A0A70; Tue, 26 Oct 2021 04:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSVUlYHGJPZe; Tue, 26 Oct 2021 04:37:41 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4362E3A0A21; Tue, 26 Oct 2021 04:37:38 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:b877:1ebd:d558:e93a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 9AB8B600CED; Tue, 26 Oct 2021 14:37:29 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1635248249; bh=7b1A4zcLK0t4i67Q4ya+oDIsDmjv+GVjD8YfhRckq/Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=mTG3wC9gsxWMAh635UYdauB9AvH6gNTej4x5D759/4ozx7YHwdMNdgJbkNNo6OQLW mnJmSa6aAVPdRbtVr2wGKqyMlpiKIuP0CZ5FoeGfkHo2z3DByVqUDdCJxwVODxM+8F Wgg75mepr/lFem6pn9s0jB8gvZ6cJ/QUtqrqe0Fw=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <163049116085.32386.13520930346743651891@ietfa.amsl.com>
Date: Tue, 26 Oct 2021 14:37:18 +0300
Cc: General Area Review Team <gen-art@ietf.org>, last-call@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDD140DC-48CF-48A8-9A1B-C981E4321155@eggert.org>
References: <163049116085.32386.13520930346743651891@ietfa.amsl.com>
To: Dan Romascanu <dromasca@gmail.com>
X-MailScanner-ID: 9AB8B600CED.A6455
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k0YCr6d0xBrQVNW-YbMlvX9XiZ0>
Subject: Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2021 11:37:47 -0000
Dan, thank you for your review and thank you all for the following discussion. I have entered a Discuss ballot for this document based on my own review. Lars > On 2021-9-1, at 13:12, Dan Romascanu via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Dan Romascanu > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dnsop-dns-tcp-requirements-12 > Reviewer: Dan Romascanu > Review Date: 2021-09-01 > IETF LC End Date: 2021-09-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Ready with minor issues and editorial comments. > > This document with intended status BCP updates RFC 1123 encouraging the > operational practice of permitting DNS messages to be carried over TCP on the > Internet. It is aligned with the implementation requirements in RFC 7766. It is > highly significant for the operators community as is the formal requirements > equivalent for the operational community, encouraging system administrators, > network engineers, and security staff to ensure DNS over TCP communications > support is on par with DNS over UDP communications and as it also considers the > consequences with this form of DNS communication and the potential operational > issues that can arise when this best current practice is not upheld. > > This document is welcome and clear for anybody who is familiar with the field. > However, because of the long history it would be useful to think ahead for > readers that will read and use 5, 10 or 20 years from now. Hence, a few > editorial comments. I put them in the Nits/editorial category, but they are > really more than nits, so I recommend that the authors consider them, before > the document gets to the RFC Editor. > > Major issues: > > Minor issues: > > 1. In Section 4.1: > >> DNS clients MAY also enable TFO when possible. > > Maybe I do not fully understand the intent here, but 'MAY ... when possible' > sounds like a SHOULD to me. > > 2.In Section 4.2 > >> DNS server software SHOULD provide a configurable limit on the total > number of established TCP connections. If the limit is reached, the > application is expected to either close existing (idle) connections > or refuse new connections. Operators SHOULD ensure the limit is > configured appropriately for their particular situation. > > DNS server software MAY provide a configurable limit on the number of > established connections per source IP address or subnet. This can be > used to ensure that a single or small set of users cannot consume all > TCP resources and deny service to other users. Operators SHOULD > ensure this limit is configured appropriately, based on their number > of diversity of users. > > The lack of recommendations about how these limits should be set would leave > less experienced operators in the dark. There is not even a sentence like 'This > document does not offer advice on particular values for such a limit' as for > other parameters in the same section. From an operators point of view I would > prefer a recommendation or one or more examples of how these limits can be set > in real life cases. > > Nits/editorial comments: > > 1. Sections in the document that are obviously for informational pursposes > should be clearly marked so (like 'This section is included for informational > purposes only'). For example Section 2. > > 2. In Section 3: > > Regarding the choice of limiting the resources a server devotes to > queries, Section 6.1.3.2 in [RFC1123] also says: > > "A name server MAY limit the resources it devotes to TCP queries, > but it SHOULD NOT refuse to service a TCP query just because it > would have succeeded with UDP." > > This requirement is hereby updated: A name server MAY limit the > resources it devotes to queries, but it MUST NOT refuse to service a > query just because it would have succeeded with another transport > protocol. > > Similar alignment of the old and new text is desirable. Even using the OLD / > NEW format. > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [DNSOP] Genart last call review of draft-ietf-dns… Dan Romascanu via Datatracker
- Re: [DNSOP] Genart last call review of draft-ietf… Wessels, Duane
- Re: [DNSOP] Genart last call review of draft-ietf… Dan Romascanu
- Re: [DNSOP] Genart last call review of draft-ietf… Petr Špaček
- Re: [DNSOP] Genart last call review of draft-ietf… Vladimír Čunát
- Re: [DNSOP] [Gen-art] Genart last call review of … Lars Eggert