Subject: Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Oct 2021 14:37:18 +0300

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art