Re: [Arcing] New Version Notification for draft-stw-whatsinaname-00.txt

Suzanne Woolf <> Tue, 12 July 2016 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5DE812D8D6 for <>; Tue, 12 Jul 2016 14:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2nw4iTNHQM_u for <>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E7D912D8BA for <>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
Received: by with SMTP id 82so26323907qko.3 for <>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gOpfH5riLEDseNf6i4Ph7e+FjWRrUqADBNVU64Mp7ik=; b=Vj+s2a0KWWjcUWPrved7zQswPLwwquKGClC9JuQC294/ty7+TSWinxqo0NoogeCTGi zTid64PbshQI9hIlc6s3Fq0yi/gNgypP6oGsEK4uGJluwezhMzVQdD2hC6NSvLm1/3RV 1jUjkVJqs/JtOU6Tht7tUCP9oF3a4XYEZXYJPd0WWvbjwD8w5ke4KahtSaR8HeWaEwl9 Y8oZMd6s/2iRFJA7LS7ky7HcepoU12Ba37pW4+HZ/f2HGbgihxaKz0vwudOoj8/eLI87 PrHTidX3q+ktMutDzcIozjmCmusVxLUHcN6A2vT3Dq10xt1kAtg/PW3tw3mEZM1oOngj obvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gOpfH5riLEDseNf6i4Ph7e+FjWRrUqADBNVU64Mp7ik=; b=LOCWJWSDVEBTTmoYw8quVxAl78qc9yUxqIPObK76Bw56k9uGGs6xVNcMD3D5AQRW1k MnkWGdkFxRnY+hM8fNjZXE5mtRj0tOblrrUajtIdQe6GDA/P+3w7rU5AVQ955+NvTm2W bSGU/sIrdmniPjKdxHNMmdznFaCpJYXKRauVoMoDf+k2qHDAEIhiOtK3lux4wrbeNHD1 ZKDDxQt+H9BbkYjx/CY27S96ja7VVhTLpQC9jGdFnwo4iak74rP1tUxmVkzxfBC3O0me YdIFtYIVC5BZ8G9zpvNYRcPYqNuJ3nHXsJo9s+EG1TFTLK3NRJ+CUgyru9Tk53mwarma ZLwQ==
X-Gm-Message-State: ALyK8tJe0jwtWf16wbJPEmR0IDz1gCSPaKzE9wYDz/6lk64yoUDb7O3F5EPkEDtaatwRYA==
X-Received: by with SMTP id x132mr5853751qka.26.1468357887091; Tue, 12 Jul 2016 14:11:27 -0700 (PDT)
Received: from ?IPv6:2601:181:c003:1360:74c9:33db:4821:4f02? ([2601:181:c003:1360:74c9:33db:4821:4f02]) by with ESMTPSA id a67sm1506497qkc.24.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 14:11:26 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <>
In-Reply-To: <20160712203057.33162.qmail@ary.lan>
Date: Tue, 12 Jul 2016 17:13:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20160712203057.33162.qmail@ary.lan>
To: John Levine <>
X-Mailer: Apple Mail (2.1510)
Archived-At: <>
Subject: Re: [Arcing] New Version Notification for draft-stw-whatsinaname-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2016 21:11:30 -0000

On Jul 12, 2016, at 4:30 PM, John Levine <> wrote:

>> There seemed to be strong feeling in the ARCING BOF in BA that we needed a document that could serve as advice to
>> protocol designers and software implementers, although it's not entirely clear where such a document should live. It's
>> *not* intended for adoption by DNSOP; although it may ultimately include advice to DNS operators, that's not the
>> primary purpose.
> I read it, and it's all reasonable and informative, but I fear it'll
> just be preaching to the converted.  The unconverted will continue to
> say "yeah, ok, I know all that but I still need to reserve .BANANA"
> We have a severe perverse incentive.  On the one hand, we tell people
> that squatting on domain names is bad for all sorts of reasons, and
> we're not going to let people reserve desirable names for non-DNS use
> for other reasons.  Then anyone who's paying attention can see that
> what you actually do is pick the name you want and squat on it with
> extreme vigor, until we say, oh, all right, just this once.  Or maybe
> we don't, but unless there's some external situation like the one for
> .onion certificates, they hand out software that uses the name they
> want anyway and if the names leak, too bad.
> Until and unless we can de-perversify the situtation, I don't see much
> point in offering more advice.

I understand this argument, but have a couple of reservations about it as a reason to just throw up our hands:

First, some people actually would probably prefer to avoid name collisions, ambiguous resolution semantics, etc. in their standards and specifications-- the resulting software is easier to write, debug, operate, and troubleshoot. A little clear thinking about what protocols you're using and what you're assuming about names can go a long way.

Probably more importantly, I don't think "there's nothing we can do" is a good answer for protocol developers within the IETF. 

See, for example, the current effort in homenet to define a naming architecture: there's already an RFC 7788bis I-D to correct the bad edit that set "home" as a default without any corresponding process for the special use names registry, but there's still a belief that they need to set a default-- and still some ambiguity about the behavior of the naming protocol they're using. "Do whatever you want, and we can't help you decide what to want" doesn't strike me as a good policy for the IETF to have for its working groups on this subject.