IETF Logo Mail Archive

Re: [DNSOP] normative language in BCPs Re: DNS Delegation Requirements

Mark Andrews <marka@isc.org> Mon, 22 February 2016 23:40 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702DD1A87B8 for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2016 15:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 0d82CVDIb9hY for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2016 15:40:56 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441A51A86DD for <dnsop@ietf.org>; Mon, 22 Feb 2016 15:40:56 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 2076F1FCAD8; Mon, 22 Feb 2016 23:40:53 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0A8EF160042; Mon, 22 Feb 2016 23:40:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F0097160091; Mon, 22 Feb 2016 23:40:51 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Mp2AqtAQ-8Nl; Mon, 22 Feb 2016 23:40:51 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id B102D160042; Mon, 22 Feb 2016 23:40:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2945F42F519B; Tue, 23 Feb 2016 10:40:49 +1100 (EST)
To: Suzanne Woolf <suzworldwide@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <3A6EF5A0-928C-4F10-BD68-265DAE87F9A8@kirei.se> <4C7298C1-4331-4953-881F-89C7BB3FED39@fl1ger.de> <CAHw9_iKDcqzW6NQkwyBh933=apjAqCDLKF7O60D5fmLm+PgLkg@mail.gmail.com> <e915c2c6f1b54b0188ee90eb753fbcb7@mxph4chrw.fgremc.it> <CAHw9_iLZfgGFTvjqXWDQvLdUUwpS-Ok3LKKzEbWqtsrQi+w==Q@mail.gmail.com> <C059877D829F76429F49E0B48705D888DDD21B4C@EXCH-01.CORP.CIRA.CA> <cd765f8368da465ea1078e20e77ea06c@mxph4chrw.fgremc.it> <20160209233439.2279C41C190F@rock.dv.isc.org> <884f1c3fc1324a96a3732c942c8a25a3@mxph4chrw.fgremc.it> <CAKr6gn2zA1DST-DuyV1Lhhfy41UrBE5AJdmy=nH65Bi-J9ja2Q@mail.gmail.com> <A1DD7FB4-3847-4E4F-A5D2-94E9144929D9@gmail.com>
In-reply-to: Your message of "Sun, 21 Feb 2016 17:37:39 -0500." <A1DD7FB4-3847-4E4F-A5D2-94E9144929D9@gmail.com>
Date: Tue, 23 Feb 2016 10:40:49 +1100
Message-Id: <20160222234049.2945F42F519B@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ZortnuFk64ZaHsXoief7O3myTy4>
Cc: dnsop <dnsop@ietf.org>, George Michaelson <ggm@algebras.org>
Subject: Re: [DNSOP] normative language in BCPs Re: DNS Delegation Requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 22 Feb 2016 23:40:57 -0000

In message <A1DD7FB4-3847-4E4F-A5D2-94E9144929D9@gmail.com>, Suzanne Woolf writ
es:
> The no-response draft has a similar issue IMO, in that it's quite
> prescriptive about what a certain set of players (TLD operators) should
> do about identified problems, and silent on advice to anyone else
> (registrars who have customer relationships with domain owners, DNS
> hosting operators, DNS implementers,...
> .)

We could just add this:

+      <t>
+	Nothing in this section precludes others testing servers
+	for protocol compliance.  DNS operators should test their
+	servers to ensure that their vendors have shipped protocol
+	compliant products.  Nameserver vendors can use these tests
+	as a part of this release processes.  Registrants can use
+	these tests to check their DNS operators servers.
+      </t>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email