Re: Update of RFC 2606 based on the recent ICANN changes ?

Keith Moore <moore@network-heretics.com> Tue, 08 July 2008 20:50 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F6228C31B; Tue, 8 Jul 2008 13:50:03 -0700 (PDT)
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 BCAB928C31B for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 13:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Level:
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 lawkk9iz53el for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 13:50:02 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id DF18428C2C6 for <ietf@ietf.org>; Tue, 8 Jul 2008 13:50:01 -0700 (PDT)
Received: from lust.indecency.org (mail.fiveman.com [72.242.14.234] (may be forged)) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AWI95720 (AUTH admin@network-heretics.com) for ietf@ietf.org; Tue, 8 Jul 2008 13:50:08 -0700 (PDT)
Message-ID: <4873D2FF.7090607@network-heretics.com>
Date: Tue, 08 Jul 2008 16:50:07 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
References: <20080708020228.GC10677@zod.isi.edu> <200807080254.m682sG2Q007427@drugs.dv.isc.org> <20080708161335.GB2519@zod.isi.edu> <4873948A.2040904@network-heretics.com> <4873AE46.6010906@isi.edu> <4873B2C0.1020008@network-heretics.com> <4873B353.20302@isi.edu> <4873B5F8.1060702@network-heretics.com> <4873B846.5070803@isi.edu> <4873B993.9040705@network-heretics.com> <4873C6FE.2000601@isi.edu> <4873CC8F.3010601@network-heretics.com> <4873CEDF.2080904@isi.edu>
In-Reply-To: <4873CEDF.2080904@isi.edu>
Cc: Ted Faber <faber@ISI.EDU>, Mark Andrews <Mark_Andrews@isc.org>, Theodore Tso <tytso@MIT.EDU>, ietf@ietf.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-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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>> It's nonsensical for an application to decide that relative names are 
>>> unacceptable, but to require users to input names as relative.
>>
>> it's nonsensical for you to unilaterally declare that such names are 
>> relative, when well over two decades of practice indicates otherwise.
> 
> I didn't declare it; 1034 did. 

Yes - but you're the one declaring that 1034 trumps decades of later 
work.  Normally the assumption would be that work can be revised as bugs 
are found or conditions change over time, and that things that had 
achieved IETF consensus since 1034 was published would be considered at 
least equal, and often superior, to earlier work.

I don't think 1034 was handed down from a mountain on stone tablets.

I believe it always was inevitable that different apps would use DNS (or 
any shared naming facility) in slightly different ways.  Yes this is 
somewhat confusing, but DNS (like the rest of the Internet) has been 
stretched far beyond its original design goals or scale.  For instance, 
we don't interpret DNS names as hostnames any more - because in the 
modern world the concept of "host name" is irrelevant in the vast 
majority of cases.

And maybe this provides an illustration of how difficult it is for us to 
use service protocols consistently from one application to another (it's 
not hard to find other examples).  But such difficulty is real and it 
reflects genuine differences in requirements from one app to the next. 
Arguably 1034 didn't even address the needs of apps existing at that 
time (email being one of those apps), much less apps that came later.

Keith
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf