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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
