Subject: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 04 Jul 2016 06:00:29 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: 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-dnssec-roadblock-avoidance/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a real
test?

2) To follow up with the tsv-art review: To avoid network as well as
server overload, would it be useful to provide further guidance, when and
how often these tests should be performed?

3) In section 6.1.  (What To Do): maybe also list logging as an option in
cases where no user is directly involved but a human might check later.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jul 2016 15:28:52 -0700

"Mirja Kuehlewind" <[email-masked]> writes:

> 1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a
>    real test?

I don't think it's possible to easily test this, sadly, without a target
set containing different deterministic response sizes.  We could
probably strike the section and simply state that resolvers MUST support
TCP (which actually is stated elsewhere). 

> how often these tests should be performed?

      <t>These tests should be performed when a resolver determines
      its network infrastructure has changed.  Certainly a resolver
      should perform these tests when first starting, but MAY also
      perform these tests when they've detected network changes
      (e.g. address changes, or network reattachment, etc).</t>

FYI, I don't think even with a lot of boxes starting at the same time it
would cause significant overload.  Specifically, those resolver boxes
are serving many more clients that will be issuing significant more
traffic once the resolver is operational than these tests actually
require.

> cases where no user is directly involved but a human might check later.

Good point.  I've changed it to:

	<t>If Host Validator detects that DNSSEC resolution is not
	possible it SHOULD log the event and/or SHOULD warn user. In
	the case there is no user no reporting can be performed thus
	the device MAY have a policy of action, like continue or
	fail. </t>
h
-- 
Wes Hardaker
Parsons

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 9 Jul 2016 15:16:18 +0200

Hi Wes,

thanks! See below.

> Am 09.07.2016 um 00:28 schrieb Wes Hardaker <[email-masked]>:
> 

In this case it probably make sense to not have an own section but mention somewhere else that the packet size can have an influence.

> traffic once the resolver is operational than these tests actually

Thanks text sounds good. I’m not worried but it always better to give some guidance otherwise the weirdest implementations might show up.

> 	the device MAY have a policy of action, like continue or

Great! Thanks!

Mirja