Skip to main content

Last Call Review of draft-ietf-dnsop-dns-error-reporting-06
review-ietf-dnsop-dns-error-reporting-06-tsvart-lc-fairhurst-2023-10-17-00

Request Review of draft-ietf-dnsop-dns-error-reporting
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-10-30
Requested 2023-10-16
Authors Roy Arends , Matt Larson
I-D last updated 2023-10-17
Completed reviews Dnsdir Telechat review of -07 by James Gannon (diff)
Intdir Telechat review of -07 by Carlos Pignataro (diff)
Tsvart Telechat review of -07 by Gorry Fairhurst (diff)
Dnsdir Early review of -04 by James Gannon (diff)
Secdir Early review of -04 by Yaron Sheffer (diff)
Tsvart Last Call review of -06 by Gorry Fairhurst (diff)
Dnsdir Last Call review of -06 by David C Lawrence (diff)
Secdir Last Call review of -06 by Yaron Sheffer (diff)
Genart Last Call review of -06 by Peter E. Yee (diff)
Assignment Reviewer Gorry Fairhurst
State Completed
Request Last Call review on draft-ietf-dnsop-dns-error-reporting by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/HPIf1Ew7OYcPhamZxrxx-CF953k
Reviewed revision 06 (document currently at 08)
Result Not ready
Completed 2023-10-17
review-ietf-dnsop-dns-error-reporting-06-tsvart-lc-fairhurst-2023-10-17-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thank you for a well written document, and it's description of the service to
be provided.

This is proposed as a "lightweight" reporting mechanism.

The method states it can be used over TCP. In this case, TCP provides the
necessary congestion control, flow control and segmentation. I did not see
additional transport concerns.

The method also states it can be used over UDP - which is equally recommended.
However, the specification for use over UDP is incomplete and raises some
transport concerns:

1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no
statement about how to mitigate the effects when these are not used.

2. There is no discussion of how to handle reports larger than the maximum UDP
datagram payload. See RFC 8085 section 3.2.

3. I think this method can in some uses could generate a stream of reports at a
rate that could be more than a few UDP datagrams per RTT, (e.g., if implement
automated responses). In this case, I think method would need to provide some
basic rate limiting or implement a form of congestion control.

I understand the rate is usually "damped" by caching to one message/TTL per
report, but I am unsure this is sufficient to mitigate any congestion control
concerns.

One potential remedy could be to require/recommend use over a
congestion-controlled transport (such as TCP) when using an Internet path;  an
alternative would be to be define appropriate mechanisms to provide at least
starvation prevention for UDP services. See RFC 8085 section 3.1.

NiT: It could be useful to expand "DS records" on first usage.