Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations

From: Arthur Thisell <[email-masked]>
Date: Sun, 9 Sep 2012 11:37:06 -0700 (PDT)

>> In particular, the table in section 9.1.1 can be easily misread as
>> saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms,
>
> Perhaps that fixes it:
>
> OLD
>   Section 4.6.4 specifies the limits receivers have to use.

I don't see how this fixes the problems with the table at all.  The most serious problem with the table is the "limits" column implies that each type of mechanism has its own limit instead of one limit for all of them.   The other problem with the table is that implies that the "cost" column is somehow related to the "limits" column, which it doesn't.

But, even if you fixed the table, it doesn't fix the problem that the draft is made worse by having even section 9.1.1.   It promotes fragile efficiency, which isn't a major problem, over SPF records being kept accurate, which is a problem.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Sep 2012 10:36:38 +0200

On Sun 09/Sep/2012 20:37:06 +0200 Arthur Thisell wrote:
> I don't see how this fixes the problems with the table at all.

Because it defines the table's header.  If you like it better:

NEWER
    Costs are the number of DNS queries required to carry out the
    test.  Limits are specified in Section 4.6.4.

> The most serious problem with the table is the "limits" column
> implies that each type of mechanism has its own limit instead of
> one limit for all of them.

That's a specification quibble that issue #24 didn't change.  Anyway,
9.1.1 is explicative, not normative.

> The other problem with the table is that implies that the "cost"
> column is somehow related to the "limits" column, which it
> doesn't.

The relationship is that limits are there in order to prevent
excessive costs, including DoS.

> But, even if you fixed the table, it doesn't fix the problem that
> the draft is made worse by having even section 9.1.1.

That sounds like "even if we fix the spec, the problem is that we'll
still have SPF around..." :-/

> It promotes fragile efficiency, which isn't a major problem, over
> SPF records being kept accurate, which is a problem.

The question of how efficiency implies fragility is fascinating, but
before we go on quoting Darwin or Knuth, let's recall it's OT.

I agree maintenance of SPF records is a problem.  To knowledgeably
update SPF records, admins need to understand the tradeoffs between
maintainability and efficiency, rather than wonder about whether they
might dare removing that "mx" that the wizard certainly had good
reasons to put there.  That's the knowledge 9.1.1 tries to provide.