Re: [DNSOP] [Ext] Lameness terminology

Paul Vixie <paul@redbarn.org> Fri, 04 May 2018 02:47 UTC

Return-Path: <paul@redbarn.org>
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 CC451129C6E for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 19:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5a0bsVrlpF7W for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 19:47:16 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3430312751F for <dnsop@ietf.org>; Thu, 3 May 2018 19:47:16 -0700 (PDT)
Received: from [10.199.5.28] (unknown [50.235.236.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5D99389289; Fri, 4 May 2018 02:47:14 +0000 (UTC)
Message-ID: <5AEBC9AF.6030008@redbarn.org>
Date: Thu, 03 May 2018 22:47:11 -0400
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
CC: Bill Woodcock <woody@pch.net>, Edward Lewis <edward.lewis@icann.org>, David Huberman <david.huberman@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Shane Kerr <shane@time-travellers.org>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <b3ed96d7-26fb-3d97-118b-39e8f352a38c@time-travellers.org> <87F43055-5B0E-4551-BD8D-241D93F9039F@icann.org> <0AA87D00-17F7-4D10-A72D-E4723C4A0642@icann.org> <B1F34038-595E-48A5-AFB6-20F3214BB8BF@isc.org> <EFC5B29C-48D2-4F5C-BF2D-26C26E302889@icann.org> <40451767-9536-448B-8BBD-A592AD430A78@pch.net> <23302F63-7B87-42B2-9A5B-DE8FF3EFA7F4@isc.org> <95D39EB7-9CF0-4DFE-AD9C-BCE61A69B4BF@pch.net> <2E0AE702-D5BE-46B7-A819-CDECE2004DD1@isc.org>
In-Reply-To: <2E0AE702-D5BE-46B7-A819-CDECE2004DD1@isc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J8E3NTy76xjoOT7dYzJH881tt9Y>
Subject: Re: [DNSOP] [Ext] Lameness terminology
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 04 May 2018 02:47:18 -0000


Mark Andrews wrote:
>> ...
>
> The problem is that you can’t just remove the NS records from the
> parent side because name servers learn the NS records from the child
> side of the delegation as well as the parent side.  The offending NS
> records need to be removed from both sides.  This (or fixing whatever
> is broken) is what should be happening when faults are reported.
> When that doesn’t happen in a *reasonable* amount of time the
> *entire* delegation needs to be removed to force the issue.

+1. it's a cooperative ecosystem. destructive noncooperation can't be 
ignored.

-- 
P Vixie