[Gen-art] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Dan Romascanu via Datatracker <noreply@ietf.org> Wed, 01 September 2021 10:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1])
by ietfa.amsl.com (Postfix) with ESMTP id E42763A1770;
Wed, 1 Sep 2021 03:12:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: dnsop@ietf.org, draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org,
last-call@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163049116085.32386.13520930346743651891@ietfa.amsl.com>
Reply-To: Dan Romascanu <dromasca@gmail.com>
Date: Wed, 01 Sep 2021 03:12:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/hEs5pjeW8oZw2HxcGgr5BpMoPJw>
Subject: [Gen-art] Genart last call review of
draft-ietf-dnsop-dns-tcp-requirements-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>,
<mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>,
<mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2021 10:12:54 -0000
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] Genart last call review of draft-ietf-d… Dan Romascanu via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Wessels, Duane
- Re: [Gen-art] Genart last call review of draft-ie… Dan Romascanu
- Re: [Gen-art] [DNSOP] Genart last call review of … Petr Špaček
- Re: [Gen-art] [DNSOP] Genart last call review of … Vladimír Čunát
- Re: [Gen-art] Genart last call review of draft-ie… Lars Eggert