Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Suzanne Woolf <suzworldwide@gmail.com> Wed, 05 July 2017 12:01 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B2132978; Wed, 5 Jul 2017 05:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 05yK57Jo313R; Wed, 5 Jul 2017 05:01:39 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 9F9CC13297E; Wed, 5 Jul 2017 05:01:35 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id 16so187503748qkg.2; Wed, 05 Jul 2017 05:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbSQWMF5YTqw4gIJCTtdbI/LZGLMXwJt/gliUZN2470=; b=Hnx/56I1hUT36A4RH9gQBy70afSlnTTSzeyt1vYvR9Bvlila6biGI6fsC/Gz1CH7OS 9l5+rRMTd5YaM9nFWluJY/yR0iFQZl9HiQkZtDWkcx0gaVFNQacjUipKJLGXL7Z9udAU yD51gHibPaetFUMYXovAwBd6gGB5Q4rq3m0RE4SMs/ARCGVW65b+CpzZTdPy0K8sMVN7 t4HWWfhjexx/rYq6OjRdNtOXiUjC2Q9nhwY/k/8JrEXO6MWRG103M+5cr9yBHYydm60h M2EY/Lsce9lCroItMhGcVfcEqsQxMfPsI5vPgoy19du/qJOQrIacRwnLIOnj/XcjnFJE PrvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbSQWMF5YTqw4gIJCTtdbI/LZGLMXwJt/gliUZN2470=; b=hZDaj5qs+WWvAckbC4m5yvmKOQjvJcPn0FsunfQH6zDdCnWuC3KucYh8oPDPAbyVam 7VlRvySbaawavUYnVPOJUESwMm5ghRaSzUkO2RUkI/jlCs3hjHTU35jiSofStKcQ80SX QDb54BpstPV9NIq1JOu6xISuMabdtDBIpUvB+eF/FWDHDY3XMJcKK7vdE3xuMkQX/KkA G30vEfzrf8hC7mUIavRCjyyozmYEhCGWAzmqiYyvFH3uRFucTvOEOLhHaTdvbMhoB93T rpIIAv5bom/In4o22zEIiIm7TxuCHmdCQUCy7/a7awQnmRPPooStLi3YQiv+usahzcok wCtg==
X-Gm-Message-State: AKS2vOzkuz4yjNKGq6OtkwOM9YKZQ/y8rYSx6vzlqjjv7IjGhlBYQ7rz 3/QshT4T9Njc4Q==
X-Received: by 10.55.139.68 with SMTP id n65mr50969999qkd.172.1499256094576; Wed, 05 Jul 2017 05:01:34 -0700 (PDT)
Received: from [10.232.156.114] ([73.114.23.114]) by smtp.gmail.com with ESMTPSA id 7sm6796572qtt.27.2017.07.05.05.01.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Jul 2017 05:01:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com>
Date: Wed, 5 Jul 2017 08:01:30 -0400
Cc: Randy Bush <randy@psg.com>, dnsop@ietf.org, IETF Rinse Repeat <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ABF6534-D3DA-42B0-AC75-57C667CC38B2@gmail.com>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dWDvWU3JbL5Vgm9bN7uzrZXsyyA>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 12:01:54 -0000

(not sure which hat. Probably doc shepherd.)

> On Jul 4, 2017, at 9:23 AM, Ted Lemon <mellon@fugue.com>; wrote:
> 
> On Jul 4, 2017, at 3:39 AM, Randy Bush <randy@psg.com>; wrote:
>> is there a companion document with the list of benefits/advantages?  or
>> is thins just one of those ietf documents from on high meant to kill
>> something?

> 
> This is a very good question. We weren’t asked to answer that question, so we didn’t.  It is assumed throughout the document that various proponents of special use domains have good reasons for wanting them, and further that it is already accepted in principle that if their reason for wanting them is valid, they can have them (modulo technical constraints like delegation). So we didn’t delve into that. But perhaps we should have. 

I’d go a step further: RFC 6761 alludes to some general reasons, but assumes people who’d go through the IETF standards process or an IESG approval process to get an entry in the special use names registry have good enough reasons that the special handling requested should be accepted as part of the DNS protocol. (I’m one of the people who isn’t comfortable with this assertion, but we’re living with what RFC 6761 says, not what I think it should have said.) 

That is, RFC 6761 leaves to other processes to assess the value of the request and the reasons offered, but strictly speaking doesn’t require them to be documented or evaluated; required documentation for the registry entry consists mostly of assessing how it interacts with the DNS, not its primary use. (Sec. 4 starts by saying “If it is determined that special handling of a name is required in order to implement some desired new functionality,” the registry entry policy applies, but openly avoids describing how that determination should be made.)

This isn’t really strange— plenty of registries don’t require any particular discussion of the merits of an entry; ISTM that “standards action” presumes such evaluation as part of IETF consensus. But it does seem like a significant part of the observed problem— there are only subjective and ad hoc bases for evaluation for a request that’s not otherwise justified by a standards track document, leading to endless repetitions of discussions like whether a new CLASS would be a “better” way to solve a problem that isn’t actually documented in the request.

I think the observation that people aren’t really required to document what problem they are trying to solve with their special use name is in the draft, but perhaps could be more explicit. 

Some few people already have been convinced that there should be some general guidance available for making the determination that a domain name requires special handling in the DNS. But that also seems to be a different document.



Suzanne