IETF Logo Mail Archive

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

Mark Andrews <Mark_Andrews@isc.org> Wed, 04 March 2009 21:02 UTC

Return-Path: <Mark_Andrews@isc.org>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43393A6D23 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 13:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b12pAv8nVY12 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 13:02:07 -0800 (PST)
Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 825CA3A6D37 for <ietf@ietf.org>; Wed, 4 Mar 2009 13:02:07 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 4D5ED11401C; Wed, 4 Mar 2009 21:02:27 +0000 (UTC) (envelope-from Mark_Andrews@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id ACB80E6064; Wed, 4 Mar 2009 21:02:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n24L2OTc027963; Thu, 5 Mar 2009 08:02:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200903042102.n24L2OTc027963@drugs.dv.isc.org>
To: ietf@ietf.org, namedroppers@ops.ietf.org
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
In-reply-to: Your message of "Wed, 04 Mar 2009 21:33:00 BST." <e90946380903041233l2685f576h66261f7308de6358@mail.gmail.com>
Date: Thu, 05 Mar 2009 08:02:24 +1100
Sender: Mark_Andrews@isc.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2009 21:02:08 -0000

	For this section to be useful you needs to be done at break
	points.  LAN  /64, SITE /56 or /48 and ISP /??.  Doing it
	on every bit boundary is just plain wrong.  The intent was
	good.  The specification was wrong.  To make this useful
	you need a protocol to distribute those break points.

	This is a little like a automated sortlist built into modern
	resolvers.

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

v2.23.0 | Report a Bug | By Email