Re: [spfbis] Revisit: Issue #36: RFC 2119 key words

[Scott Kitterman <[e-mail]>]

Alessandro Vesely <[e-mail]> wrote:

>On Sat 09/Feb/2013 01:51:23 +0100 Scott Kitterman wrote:
>> On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote:
>>>>> -- Section 4.6.4 --
>>>>> In the second paragraph, why are you mixing "MX resource records"
>in
>>>>> the first sentence with "A resource records" in the second
>sentence?
>>>>> Is this a typo, or intentional?  If it's intentional, I would
>re-word
>>>>> it, which will probably correct the odd "MUST".
>>>> 
>>>> When I look at it, I think it says that, but obviously it's not
>clear.
>>>> Wording suggestions appreciated.
>>> 
>>> Right, but you start by talking about how many MX lookups there are.
>>> What you say in your explanation above is that there's one, and the
>>> issue is how many A records that expands to.
>>> 
>>> As written, it seems to say that you can do up to 10 MX lookups, and
>>> each of those can result in up to 10 A lookups, for a total of 110
>DNS
>>> lookups.  Is that what you mean?
>> 
>> Yes.  This is the basis for the infamous 111 DNS lookups.
>
>Can't we remove those paragraphs, please?  They're just misplaced, and
>break the One Definition Rule.  I'd propose something like:
>
> The "mx" and "ptr" mechanisms, and the %{p} macro, are subject to
> their own limits, as specified in the corresponding sections below,
> which are in addition to the lookup limits specified in this section.
>
> NOTE:
>   The limit for "mx" (Section 5.4) is treated differently from the
>   limit for "ptr" and the %{p} macro (Section 5.5).  The reason for
>   that disparity is that the set of and contents of the MX record
>   are under control of the domain owners, while the set of and
>   contents of PTR records are not always delegated and can thus be
>   under control of their network providers.
>
>Text like that could replace all of the four central paragraphs of
>Section 4.6.4.
>
>BTW, Section 5.5 should recall that part of it is also valid for the
>%{p} macro.
>
>jm2c

We can't organise it like that because they are part of an overall 10 lookuplimit that is not per mechanism. 

Scott K