Re: [DNSOP] draft-liman-tld-names-04

Suzanne Woolf <woolf@isc.org> Sat, 27 November 2010 18:49 UTC

Return-Path: <woolf@isc.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 0B2CA28C0DB for <dnsop@core3.amsl.com>; Sat, 27 Nov 2010 10:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level:
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 2caNxNLXkxqS for <dnsop@core3.amsl.com>; Sat, 27 Nov 2010 10:49:07 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 18B3528C0D7 for <dnsop@ietf.org>; Sat, 27 Nov 2010 10:49: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.pao1.isc.org (Postfix) with ESMTPS id BCA41C942D for <dnsop@ietf.org>; Sat, 27 Nov 2010 18:50:10 +0000 (UTC) (envelope-from woolf@isc.org)
Received: by farside.isc.org (Postfix, from userid 10265) id 8A808E6056; Sat, 27 Nov 2010 18:50:10 +0000 (UTC)
Date: Sat, 27 Nov 2010 18:50:10 +0000
From: Suzanne Woolf <woolf@isc.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20101127185010.GB56062@farside.isc.org>
References: <4CEC69C5.3040209@dougbarton.us> <7B9EF625-1E25-42BE-9546-61C5B7EFC6DA@hopcount.ca> <8CEF048B9EC83748B1517DC64EA130FB43E0037FD1@off-win2003-01.ausregistrygroup.local> <20101124142303.GB19441@shinkuro.com> <alpine.LSU.2.00.1011251734170.4075@hermes-2.csi.cam.ac.uk> <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk> <D8E75C03-0322-4594-BB27-D825AB429EA6@hopcount.ca> <C4FB358F-53D1-4A2B-A3A4-1C07222C0B51@dotat.at> <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [DNSOP] draft-liman-tld-names-04
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, 27 Nov 2010 18:49:08 -0000

On Sat, Nov 27, 2010 at 01:25:21PM -0500, Joe Abley wrote:
> We're talking about an era where documentation was often not
> especially rigourous, and when the state of the network frequently
> depended on information that existed only in peoples' heads, or
> pragmatically in software produced by early implementors. Maybe a
> reference to the restriction is as much as we can hope for from
> 1123.

I think the fact that this discussion has gone on so long and
encumbered so many electrons supports the contention underlying the
draft that there is an ambiguity, based exactly as Joe suggests here.

The draft carefully doesn't rely on any assertion of a prior
restriction as the basis for clarifying the spec as we want it to be
today. It does assert the ambiguity that I think we're busily
demonstrating in this discussion.

Old specs are full of such ambiguities, which are mostly harmless
because they don't harm interoperability or the potential harms have
been addressed by implementors in practice. In this particular case,
hwoever, the "interoperability" boundary could reasonably be argued to
be between protocol and policy as much as between implementations.

Rather than explaining to either future implementors or people whose
primary orientation is policy that "we couldn't agree there was any
ambiguity here that we needed to address," or "some protocol standards
are more equal than others," let's make this unambiguously normative.


Suzanne