IETF Logo Mail Archive

Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document

Keith Moore <moore@network-heretics.com> Fri, 21 October 2011 01:39 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A575C1F0C47; Thu, 20 Oct 2011 18:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.792
X-Spam-Level:
X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jidTSuKNg4Vu; Thu, 20 Oct 2011 18:39:27 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 034D71F0C3C; Thu, 20 Oct 2011 18:39:27 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 88D7E2067F; Thu, 20 Oct 2011 21:39:26 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 20 Oct 2011 21:39:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=63q2SBi6u8A4nDGLr3DDLXaMfps=; b=Rn rO5oMbPjMub7bH20PmCW391uID4P7/95wKfDFEcD+JA6w/JPnwL6eVdk36l7Dasg ZQhJ+/MVWSJ8GmjRy9Q/VJnph02tb8SylgtB26Q7ihKJ3an1ObEC/McCIDV03aOi T80Ds01OsXKVs00vwm3rKN2xjS9d/gRssXPamEtqs=
X-Sasl-enc: 4NGv0e7cIBi+zvGFuuisqbcmpKgbEx9ToGkpLUFi34x7 1319161166
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B70494833A4; Thu, 20 Oct 2011 21:39:24 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org>
Date: Thu, 20 Oct 2011 21:38:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <C8398996-79B5-437E-82A5-6B869ECF8F4E@network-heretics.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1084)
Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com
Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2011 01:39:27 -0000

On Oct 20, 2011, at 9:19 PM, David Conrad wrote:

> On Oct 20, 2011, at 6:07 PM, Keith Moore wrote:
>> It might that IETF should consider "bare names" out of its scope, except perhaps to say that they're not DNS names, they don't have to necessarily be mappable to DNS names, and that their use and behavior is host and application-dependent.
> 
> Can we please not redefine what a "DNS name" is to meet a particular agenda?

I wasn't trying to do so.

> Isn't it sufficient to say a 'bare name' does not conform to a hostname as defined in RFC 952 and modified by RFCs 1122?

Probably.  I'm just suggesting that trying to nail down the behavior of such names is probably a rathole as well as likely to cause significant disruption.

v2.23.0 | Report a Bug | By Email