[DNSOP] Registration requirement (Was: Re: I-D Action: draft-ietf-dnsop-attrleaf-02.txt)

Dave Crocker <dcrocker@bbiw.net> Mon, 10 April 2017 13:36 UTC

Return-Path: <dcrocker@bbiw.net>
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 5C7491294E0 for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 06:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbiw.net
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 xzVRWBRf8DAN for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 06:36:06 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C94129498 for <dnsop@ietf.org>; Mon, 10 Apr 2017 06:29:59 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v3ADWAsq001995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Apr 2017 06:32:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1491831131; bh=XDwY7ETVD9PfnhTKOB8sdu4Ug0P8gqxeoDZeQCv6YCQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DxaLp1yBJc5jKjqtHO7FJfcw6zeQhe7AllZDi7jJ34L+LZWd0MctDWk+Q3BM2gOm5 c01Dqes17IcSQDZR+ry3ZaoTr98bg1trzb88FMUhjn61mW5ckCkC4m3rXS934Cexdo 70OOmT+zmW/F1ejLeh9OyRFy028yK9pUUdJeFPy0=
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, dnsop@ietf.org
References: <149080054550.26806.17675916795295413492@ietfa.amsl.com> <20170331155217.GA19647@laperouse.bortzmeyer.org>
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
Message-ID: <88b97201-4a1d-5378-7f8a-907abe0943bc@bbiw.net>
Date: Mon, 10 Apr 2017 06:29:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <20170331155217.GA19647@laperouse.bortzmeyer.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WS2_VQY1x6WAybPylcilpqHgc2Y>
Subject: [DNSOP] Registration requirement (Was: Re: I-D Action: draft-ietf-dnsop-attrleaf-02.txt)
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: Mon, 10 Apr 2017 13:36:07 -0000

On 3/31/2017 8:52 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 29, 2017 at 08:15:45AM -0700,
>   internet-drafts@ietf.org <internet-drafts@ietf.org> wrote
>   a message of 43 lines which said:
> 
>>          Title           : DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves
>>          Author          : Dave Crocker
>> 	Filename        : draft-ietf-dnsop-attrleaf-02.txt
> 
> Section 5 "IANA considerations" does not use the names of standard
> policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor

Thanks.  I hadn't registered that issue...


> queue, says "It is not strictly required that documents use these
> terms [the standard policies]; the actual requirement is that the
> instructions to IANA be clear and unambiguous.  However, use of these
> terms is strongly recommended because their meanings are widely
> understood."
> 
> Therefore, I suggest to replace "have been specified in any published
> RFC, or are documented by a specification published by another
> standards organization" by "specification required (RFC 5226bis,
> section 4.6).

Hmm. The IANA draft's 'Specification Required' (Section 4.6) imposes a 
requirement both for a designated expert AND the existence of a publicly 
published spec.

My original thought was that this registry should have a concern for 
stability of the reference using it, but not impose much of a barrier in 
terms of quality.  (I figured that the other document's standards 
criteria would suffice for that.)

While some registries do need careful quality control for each entry, 
this doesn't seem like it should be one of them.  The namespace is 
essentially infinite, so we don't have to worry about exhaustion, and I 
don't see much downside in letting the market decide whether the entry 
is useful.

So on reflection, I'm starting to wonder about instead going to the 
lesser First Come First Served (Section 4.4 of the IANA draft).  This 
should encourage early (pre-standards) registration.

It also should cover established practice that doesn't provide the level 
of documentation one would wish for.  Which fact you've nicely 
documented next...


Thoughts?


> Also, the proposed initial registry includes:
> 
>   SPF        | _spf         | "TXT" | [RFC7372]
> 
> RFC 7372 contains *nothing* about that, and SPF (RFC 7208) does not
> use undesrscore names.

(Yeah.  RFC 7372 is wrong.  It should be RFC 7208.  However...)


1. RFC 7208 notes the TXT ambiguity problem

    3.  SPF Records
    ...
    Since TXT records have multiple uses, beware of other TXT records
    published there for other purposes.  They might cause problems with
    size limits (see Section 3.4), and care has to be taken to ensure
    that only SPF records are used for SPF processing.

2. It requires use of TXT

    3.1.  DNS Resource Records

    SPF records MUST be published as a DNS TXT

4.  All of the examples that explicit show the TXT RR show domain names 
that do NOT use a _spf node name.  (sigh)

5.  However the document also is littered with examples of using ._spf. 
(sigh)

6.  And finally, industry documentation for SPF is loaded with 
directions for use of ._spf.  E.g.,

      http://www.openspf.org/FAQ/Common_mistakes

      Sometimes an ISP will create a special SPF record that customers
      can include with their record, such as _spf.example.com.


So we have extensive, established practice, though one could wish for a 
(much) better specification.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net