Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt

Warren Kumari <warren@kumari.net> Wed, 03 July 2013 17:36 UTC

Return-Path: <warren@kumari.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 71D7421F9CD7 for <dnsop@ietfa.amsl.com>; Wed, 3 Jul 2013 10:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P15PJu3RQ+VB for <dnsop@ietfa.amsl.com>; Wed, 3 Jul 2013 10:36:07 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A374121F9CD4 for <dnsop@ietf.org>; Wed, 3 Jul 2013 10:36:02 -0700 (PDT)
Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 4FE611B407D8; Wed, 3 Jul 2013 13:36:01 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_1C4C485A-8167-4736-92B7-DF172F04A068"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <51D2A674.4040002@sidn.nl>
Date: Wed, 03 Jul 2013 13:35:52 -0400
Message-Id: <24605594-9FF5-4DB1-BD25-998173B35521@kumari.net>
References: <20130701214044.559.35489.idtracker@ietfa.amsl.com> <13014C34-CAC8-4B5C-BF8C-C16A3770536C@kumari.net> <51D2A674.4040002@sidn.nl>
To: Antoin Verschuren <antoin.verschuren@sidn.nl>
X-Mailer: Apple Mail (2.1508)
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 03 Jul 2013 17:36:12 -0000

On Jul 2, 2013, at 6:07 AM, Antoin Verschuren <antoin.verschuren@sidn.nl> wrote:

> Signed PGP part
> Op 01-07-13 23:43, Warren Kumari schreef:
> > Hi there,
> > 
> > We would like to draw your attention to a new draft.
> 
> I like this draft and concept, but how new is it?

Not very :-)

> It's good to be documented though.
> 

Thank you! INd a(and RFCs) to me seem like a reasonable place to document implementation advice, warnings, etc, regardless of if they require protocol change or affect interoperability.

> I feel like when a recursive resolver has implemented HAMMER, and
> HAMMER_TIME is set to zero, we have an existing sticky resolver.

Yup. 

> 
> One thing that fails though for this analogy to be complete, is how
> iterative the "cache fill" query will be.
> If a record from a zone is about to expire, but it still has a valid
> NS set for that zone in it's cache, will it ignore or use that NS set
> to issue the iterative query?
> If it does use it, thereby being a full sticky resolver, it will
> create less DNS traffic for static delegated zones, as it does not hit
> the parent again.
> If it doesn't, and ignores the NS set for the zone in it's cache, and
> re-queries the parent, it will hit the parent harder than when it did
> not implement HAMMER, and probably create more DNS traffic than
> without HAMMER.
> 
> I feel this needs to be clarified in the draft.

Yup, good point.
W

> 
> 
> - -- 
> Antoin Verschuren
> 
> Technical Policy Advisor SIDN
> Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands
> 
> P: +31 26 3525500  M: +31 6 23368970
> Mailto: antoin.verschuren@sidn.nl
> XMPP: antoin.verschuren@jabber.sidn.nl
> HTTP://www.sidn.nl/
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. 
   ---maf

Warren Kumari
warren@kumari.net