[DNSOP] Tsvart last call review of draft-ietf-dnsop-avoid-fragmentation-15
Reviewer: Mirja Kühlewind 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-...@ietf.org if you reply to or forward this review. Thanks for the document; it's straight-forward but probably important to write down. I have two editorial comments and one request: 1) I would really recommend including "IP" in the document title to be absolute clear about the scope. So renaming to "IP Fragmentation Avoidance in DNS". 2) This sentence is really hard to read: "TCP avoids fragmentation using its Maximum Segment Size (MSS) parameter, but each transmitted segment is header-size aware such that the size of the IP and TCP headers is known, as well as the far end's MSS parameter and the interface or path MTU, so that the segment size can be chosen so as to keep the each IP datagram below a target size." Maybe split it into two sentences: "TCP avoids fragmentation by segmenting data into packets that are smaller than or equal to the Maximum Segment Size (MSS). As for each transmitted segment the size of the IP and TCP headers is known, the IP packet size can be chosen to keep it below the other end's MSS and path MTU." 3) In R8 you mention a timeout. Is it already anywhere specified how to set such a time for DNS retransmissions? If so, I think a reference would be useful. If not, more guidance is need to avoid network overload. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Reviewer: Mirja Kühlewind 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-...@ietf.org if you reply to or forward this review. Thanks for the well-written document! I have a couple of points below regarding the recommend TCP tuning in section 4. Other parts of the document don't seem to have any transport issues and are clear to me. First a minor comment here: "TCP connection timeout, which is often around 60-120 seconds." I guess this value relates to an RTO of 1s and 6 SYN retries which is the default in Linux. Maybe say that...? I also recommend to add a link to RFC6298. And a more general comment on section 4.2: this section takes about various limits but doesn't recommend any values. I understand that there is not a one-fits-all solution here but not knowing how to set these values correctly might scared people aways from supporting TCP. So I think having a discussion either of default values or how to derives these values based on a certain configuration would be a very valuable contribution in this document. Similarly section 4.3 talks about tuning net.ipv4.tcp_fin_timeout, however, it doesn't provide any guidance on how to tune it; Linux recommend a value of 15-30 seconds. Also setting net.ipv4.tcp_fin_timeout to a too low value and net.ipv4.tcp_tw_reuse to 1 can cause trouble and should not be done for the general case. So I don't think that guidance is appropriate without further discussion of the risks. Please reconsider this part of the document! On section 4.4, maybe mention TCP fast open here again as well? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-rfc2845bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ -- COMMENT: -- I only had limited time for a quick review of this document, so I might not be aware of all the needed background and details. Still I have two quick questions on retries: 1) Sec 5.2.3: "Implementations should be aware of this possibility and be prepared to deal with it, e.g. by retransmitting the rejected request with a new TSIG once outstanding requests have completed or the time given by their time signed plus fudge value has passed." I might not be aware of all protocol details and maybe this is already specified somewhere: While unlikely, it is possible that a request might be retransmitted multiple times, as that could cause president congestion over time, it's always good practice to define a maximum number of retransmissions. If that is already defined somewhere, maybe adding a note/pointer would be good as well. 2) Sec 5.3.1: " This allows the client to rapidly detect when the session has been altered; at which point it can close the connection and retry." When (immediately or after some waiting time) should the client retry and how often? You further say "The client SHOULD treat this the same way as they would any other interrupted transfer (although the exact behavior is not specified here)." Where is that specified? Can you provide a pointer in the text? 3) Sec 8. Shared Secrets: Would it be appropriate to use more normative language here? There are a bunch of lower case shoulds in this section; is that on purpose? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-7706bis-10: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-7706bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ -- COMMENT: -- Small editorial comment: As this document obsoletes RFC7706 (and does not update it), section 1.1 should probably be called "Changes from RFC7706" (and not " Updates from RFC 7706"). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-serve-stale-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ -- COMMENT: -- Two comments: 1) It seems to me that this sentence in section 7 should/could actually be phrased as a normative requirement in this document: "it is not necessary that every client request needs to trigger a new lookup flow in the presence of stale data, but rather that a good-faith effort has been recently made to refresh the stale data before it is delivered to any client." Maybe worth considering... 2) I find the Implementation Status section (8) actually quite interesting for this document and maybe it should be considered to keep it in the document for final publication. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-algorithm-update-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ -- COMMENT: -- I wonder if it makes sense to keep section "4.1. DNSKEY Algorithms" with the table in the document. Of course this is only a current snapshot but probably gives readers also in future a good indication with tools to look at. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
