[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)

Mirja Kühlewind via Datatracker <noreply@ietf.org> Wed, 11 March 2020 13:45 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-rfc2845bis@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Benno Overeinder <benno@NLnetLabs.nl>, benno@NLnetLabs.nl
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <158393431056.1552.14743287726077402362@ietfa.amsl.com>
Date: Wed, 11 Mar 2020 06:45:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w91AgjNTHtjaVOWyTD_FLevR1q8>
Subject: [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] Mirja Kühlewind's No Objection on draft-i… Mirja Kühlewind via Datatracker