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

John C Klensin <john-ietf@jck.com> Wed, 05 July 2017 12:49 UTC

Return-Path: <john-ietf@jck.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 9AD6A131CE1; Wed, 5 Jul 2017 05:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 b-VwcKcSxa2q; Wed, 5 Jul 2017 05:49:24 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783D11329D8; Wed, 5 Jul 2017 05:49:22 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1dSjk7-000DNX-Hd; Wed, 05 Jul 2017 08:49:19 -0400
Date: Wed, 05 Jul 2017 08:49:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
cc: Ted Lemon <mellon@fugue.com>, dnsop@ietf.org, IETF Rinse Repeat <ietf@ietf.org>
Message-ID: <1D0C8C6993058C5A6A40ABB8@JcK-HP5.jck.com>
In-Reply-To: <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> <2ABF6534-D3DA-42B0-AC75-57C667CC38B2@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lAkVUZuLlfImfMnlbD8YE6wH-KY>
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:49:26 -0000


--On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf
<suzworldwide@gmail.com> wrote:

> (not sure which hat. Probably doc shepherd.)
>...

>> 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.)
>...
> 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,

Independent of "general guidance", I think the combination of
the I-D, this thread to date, and your comments above make an
extremely strong case for updating RFC 6761 to require
documentation of the problem and discussion of other
alternatives and why they are unworkable.  Whatever else the
problem statement does, I think it makes it clear that yet
another special name should be viewed as a preference only if
there are no reasonable alternatives rather than, e.g., an
option for global vanity names.  

While "general guidance for making the determination" would be,
IMO, desirable, I can imagine months (or years) of quibbling
before agreement could be reached on such criteria.  In the
interim, I'd think a requirement for documentation and
explanation sufficient to satisfy the IETF would be in order if
only as an interim measure to prevent proposals whose main
justification is "because I want one of my very own".

Anyone in DNSOP want to write a one-page RFC?

   john