> On 7 Dec 2023, at 12:33, Gorry Fairhurst via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Gorry Fairhurst > Review result: Ready with Issues > > 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@xxxxxxxx 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. > > Thius is an updated review for -07, which addressed some of the previous issues. > > 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. What ought > someone to do when this is not done? It is recommended that the client (the resolver) sets the DNS COOKIE. The benefit of using cookies is for the client. It is to make sure that the response is genuine. However, there is little value in the response. The actual value for error-reporting is to the authoritative server that may have an issue. When cookies are not set, or are not used, there is language that states the following: The monitoring agent SHOULD respond to queries received over UDP that have no DNS COOKIE set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query over TCP. I hope this is sufficient. > 2. New text was added to note how to handle reports larger than the maximum UDP > datagram payload. (This is likely resolved in -07.) yes. > 3. I think this method could in some uses generate a stream of reports at a > rate that could be more than a few UDP datagrams per RTT, (e.g., if implementing > 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 perreport, but I am unsure > whether this is sufficient to mitigate any congestion control concerns. > Additional text may still be needed. I will add some text to that effect. How about: The reporting resolver should rate limit the number of error reports send to a monitoring agent. The maximum number of concurrent reporting is 1. This limits the rate to be one UDP datagram per RTT. Is this sufficient? Warmly, Roy -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
