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 . 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.