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

[Dave Crocker <[e-mail]>]

On 3/31/2017 8:52 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 29, 2017 at 08:15:45AM -0700,
>   [e-mail] <[e-mail]> 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