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

Wes Hardaker <wjhns1@hardakers.net> Fri, 08 July 2016 22:28 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9712D945; Fri, 8 Jul 2016 15:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjRDhMKsnwxR; Fri, 8 Jul 2016 15:28:54 -0700 (PDT)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8AE12D8D5; Fri, 8 Jul 2016 15:28:54 -0700 (PDT)
Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0E4DD28510; Fri, 8 Jul 2016 15:28:52 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
References: <20160704130029.2538.66335.idtracker@ietfa.amsl.com>
Date: Fri, 08 Jul 2016 15:28:52 -0700
In-Reply-To: <20160704130029.2538.66335.idtracker@ietfa.amsl.com> (Mirja Kuehlewind's message of "Mon, 04 Jul 2016 06:00:29 -0700")
Message-ID: <0l4m7zwyqj.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3PcUJa1njCfXNNRDCw0YiXfuISs>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 22:28:56 -0000

"Mirja Kuehlewind" <ietf@kuehlewind.net> 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). 

> 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?

      <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.

> 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.

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