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

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Sun, 28 November 2010 00:37 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
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 4EA673A6B33 for <dnsop@core3.amsl.com>; Sat, 27 Nov 2010 16:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level:
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 sQJr-6AcDsgG for <dnsop@core3.amsl.com>; Sat, 27 Nov 2010 16:37:12 -0800 (PST)
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id D2C5828C0CE for <dnsop@ietf.org>; Sat, 27 Nov 2010 16:37:11 -0800 (PST)
Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id oARNCLx0050105 for <dnsop@ietf.org>; Sat, 27 Nov 2010 18:12:21 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <4CF1A46F.9040207@abenaki.wabanaki.net>
Date: Sat, 27 Nov 2010 19:38:07 -0500
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
Organization: wampumpeag
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20101117091928.GA30093@nic.fr> <4CE9E942.20906@dougbarton.us> <0E561274-43FE-4657-951E-74C8FF0FD307@hopcount.ca> <4CEC43DC.1060709@dougbarton.us> <E7796748-6880-4928-B96D-0024E27E98D5@hopcount.ca> <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>
In-Reply-To: <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sun, 28 Nov 2010 00:37:15 -0000

On 11/27/10 1:25 PM, Joe Abley wrote:
...
> That argument speaks to the question of whether 1123 imposes a requirement, but not whether the requirement discussed in 1123 existed. The fact that it was discussed, in a DISCUSSION section as you point out, surely suggests that it did exist, and absent any subsequent clarification, presumably still does.

921 contained an alpha-only restriction on the first character in 
simple names, repeated for hierarchical names.

as the protocol did not exist when jon wrote 921 (1984), and would not 
exist for another three years, when paul wrote 1034/35, let alone five 
years later when bob edited 1122/23, which i and many others worked 
on, and no doubt introduced errors, the "restriction" is protocol 
independent.

> 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.

agree on the lack of rigor in documentation. disagree on the lack of 
rigor in test case specification (which is what a bake-off is), though 
the test cases themselves frequently were not committed to archival 
documentation.

software architecture comes in many forms, and formal specification is 
only one of them.

your claim reduces to a "2b" test case, which when fed to some dns 
iut, caused other than expected results, if present as the anchor 
proximal label, but not if present as any other label. does anyone 
actually have an equivalent test case in their regression suite?

> I still don't feel that the assertion that no requirement existed is defensible.

if you could point to an implementation, circa 1983, for which an 
interoperable standard was subsequently created in 921, or circa 1987, 
when paul wrote his implementation and documented it as 1034/35, for 
which an assumed protocol restriction can be supported by software 
forensics, or later, when bob edited 1122/23, that would tend to 
support your position.

assuming you can do any one of these three things, how large the 
installed base of that particular assumed protocol restriction is the 
next question to ask.

-e