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