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