Re: [dnsext] I-DAction:draft-ietf-dnsext-aliasing-requirements-00.txt

"George Barwood" <george.barwood@blueyonder.co.uk> Thu, 24 February 2011 22:28 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30AF3A680D for <dnsext@core3.amsl.com>; Thu, 24 Feb 2011 14:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.766
X-Spam-Level:
X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
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 W8tMhz1s4Skn for <dnsext@core3.amsl.com>; Thu, 24 Feb 2011 14:28:58 -0800 (PST)
Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id C03693A6808 for <dnsext@ietf.org>; Thu, 24 Feb 2011 14:28:57 -0800 (PST)
Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Psjgx-0000Rj-0h; Thu, 24 Feb 2011 22:29:47 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from <george.barwood@blueyonder.co.uk>) id 1Psjgh-0004dL-As; Thu, 24 Feb 2011 22:29:31 +0000
Message-ID: <0440B44C7532424EA1D0FE7ED79447EF@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: Suzanne Woolf <woolf@isc.org>, dnsext@ietf.org
References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org>
Date: Thu, 24 Feb 2011 22:30:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Subject: Re: [dnsext] I-DAction:draft-ietf-dnsext-aliasing-requirements-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2011 22:29:00 -0000

The draft gets to the heart of the issue here

   One aspect of this is
   the notion or expectation that multiple sets of names may be similar
   to a human user, and expected to behave "the same" or as "aliases" of
   one another, across multiple services and interactions.

It seems to me that in fact the number of variations of a complete name will be quite small in practice.

There will be cultural conventions for the correct "spelling", in some cases there may be a few alternative conventions.

It's not hard to handle a moderate number of variations in DNS : it may impose some additional overhead, but sensible tools for administering domains and registrations should minimise this.

Again at the application level, proper tools for handling variations are quite straightforward - it should be straightforward to configure web, email and other servers to recognise standard variations.

Where the draft states:

   Howeverer, it is not
   clear how much of the user and operator requirements for "aliases"
   can be met by mechanisms for provisioning DNS zones, at acceptable cost.

I don't believe the costs are actually unacceptable at all.

Besides, users these days do not type domain names very often - when looking for an website we usually use search engines. One might give an email address over the phone, but this is not an everyday event.

So I think the current situation is not as bad as has been implied, and therefore it is only worthwhile pursuing technical changes to the DNS standard if the costs of such changes are low, which I doubt.

George