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

Suzanne Woolf <suzworldwide@gmail.com> Tue, 12 July 2016 21:11 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DE812D8D6 for <arcing@ietfa.amsl.com>; Tue, 12 Jul 2016 14:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nw4iTNHQM_u for <arcing@ietfa.amsl.com>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7D912D8BA for <arcing@ietf.org>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id 82so26323907qko.3 for <arcing@ietf.org>; Tue, 12 Jul 2016 14:11:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.74.138 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 smtp.gmail.com with ESMTPSA id a67sm1506497qkc.24.2016.07.12.14.11.26 (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 <suzworldwide@gmail.com>
In-Reply-To: <20160712203057.33162.qmail@ary.lan>
Date: Tue, 12 Jul 2016 17:13:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <68618C98-DCC2-41B6-869D-F470589B1C1C@gmail.com>
References: <20160712203057.33162.qmail@ary.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/arcing/ZdMqyVzbvPhdfgXcMGuLfi00gFU>
Cc: arcing@ietf.org
Subject: Re: [Arcing] New Version Notification for draft-stw-whatsinaname-00.txt
X-BeenThere: arcing@ietf.org
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 <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 21:11:30 -0000

On Jul 12, 2016, at 4:30 PM, John Levine <johnl@taugh.com> 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.


Suzanne