On 3/31/2017 8:52 AM, Stephane Bortzmeyer wrote:
On Wed, Mar 29, 2017 at 08:15:45AM -0700,
[email protected] <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
