[DNSOP] Value of 4641bis

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 23 January 2010 17:46 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3661F3A6965 for <dnsop@core3.amsl.com>; Sat, 23 Jan 2010 09:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level:
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 8I25WF6bRQMD for <dnsop@core3.amsl.com>; Sat, 23 Jan 2010 09:46:04 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 57DFD3A692D for <dnsop@ietf.org>; Sat, 23 Jan 2010 09:46:04 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0NHa3Ct038488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 10:36:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240889c780e33872cf@[10.20.30.158]>
In-Reply-To: <F3F90A9A-440E-462E-8E74-CDF5C35452E6@virtualized.org>
References: <a06240810c77e721d038d@10.31.200.228> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> <d3aa5d01001211326s15ecb953tcef30444f07b03d4@mail.gmail.com> <a06240800c77e784bf4ec@[10.31.200.228]> <B02DAB14-03E2-49EF-ABDD-C0542F0FC04F@dnss.ec> <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com> <BDB79242-227E-41C9-AF10-674948A552D4@dnss.ec> <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com> <20100122152302.GA22286@vacation.karoshi.com.> <20100123001706.GB85026@shinkuro.com> <F3F90A9A-440E-462E-8E74-CDF5C35452E6@virtualized.org>
Date: Sat, 23 Jan 2010 09:36:03 -0800
To: David Conrad <drc@virtualized.org>, Andrew Sullivan <ajs@shinkuro.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org
Subject: [DNSOP] Value of 4641bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 23 Jan 2010 17:46:05 -0000

At 6:07 PM -0800 1/22/10, David Conrad wrote:
>Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (presuming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.

You are. People will tell operators "an RFC exists that covers your operation, so you must follow it". We see that all the time in the IETF in general, and I believe at least one person said it at the mic at the DNSOP WG in Dublin.

Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one model when another might have made more sense for them.

--Paul Hoffman, Director
--VPN Consortium