Re: [Gen-art] Fwd: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt

[Brian E Carpenter <[e-mail]>]

Restoring the Gen-ART CC since we need the discussion in the archive.

Thanks Murray, see below...

On 2012-06-07 06:12, Murray S. Kucherawy wrote:
> For some reason you were dropped from the Cc: list.  Forwarding for your
> consideration.
> 
> ---------- Forwarded message ----------
> From: Murray S. Kucherawy <[e-mail]>
> Date: Wed, Jun 6, 2012 at 9:50 PM
> Subject: Re: [spfbis] Gen-ART LC review of
> draft-ietf-spfbis-experiment-09.txt
> To: S Moonesamy <[e-mail]>
> Cc: [e-mail], [e-mail]
> 
> 
> On Wed, Jun 6, 2012 at 8:30 AM, S Moonesamy <[e-mail]> wrote:
> 
>> -------------
>>> IMHO section 3.1 needs several clarifications:
>>>
>>> "These surveys selected substantial sets of distinct domain names..."
>>>
>>> Were these exclusively domain names with MX records?
>>>
> Is that an important thing to state?  I don't believe it is.  They're
> domain names seen on incoming email in some way.

OK, it's necessary and sufficient to state that.

> 
>>> Also in section 3.1 there are several tables like:
>>>
>>>    "+------------------+-----------+-------+
>>>     | Domains queried  | 1,000,000 |   -   |
>>>     | TXT replies      |   397,511 | 39.8% |
>>>     | SPF replies      |     6,627 | <1.0% |
>>>     | SPF+TXT replies  |     6,603 | <1.0% |
>>>     | spf2.0/* replies |     5,291 | <1.0% |
>>>     +------------------+-----------+-------+"
>>>
>>> It is not explained what is meant by "TXT replies" and "SPF+TXT replies".
>>>
> The section is discussing RRTYPEs, so TXT refers to TXT RRTYPEs (type 16)
> and SPF refers to SPF RRTYPEs (type 99).

As noted below there are 9 different combinations and you only have 4 rows.
It's ambiguous data.

>>> Does "TXT replies" mean *any* kind of TXT record, or only TXT records that
>>> start with "v=spf"?
>>>
> That's a fair question.  I'll update the draft accordingly.
> 
> 
>>> Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for
>>> these
>>> FQDNs? If so, are they identical? (Presumably they should be.)
>>>
> Yes to the first question.  We didn't evaluate the second.
> 
> 
>>> At the moment I can't fully understand the significance of the results.
>>>
> The picture they're trying to paint is twofold: (a) the uptake of type 99
> records versus type 16 records; and (b) for type 16 records, the number of
> attempts to cause receivers to apply PRA, which is part of Sender ID.
> Substantial uptake of either type 99 records or type 16 records that
> request PRA processing would be an indicator of substantial interest in
> Sender ID.  The data show neither is present.
> 
> 
> 
>>> Also, RFC4406 states that "Sending domains MAY publish either or both
>>> formats"
>>> (i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine
>>> rows
>>> in the results table:
>>>
>>> SPF RR only, spf1 only
>>> SPF RR only, spf2.0 only
>>> SPF RR only, spf1 and spf2.0
>>> TXT RR only, spf1 only
>>> TXT RR only, spf2.0 only
>>> TXT RR only, spf1 and spf2.0
>>> SPF and TXT RRs, spf1 only
>>> SPF and TXT RRs, spf2.0 only
>>> SPF and TXT RRs, spf1 and spf2.0
>>>
> I think this will provide more clutter than clarity.  The answer to the
> over-arching question, namely "Which one has greater uptake?", is already
> available without this breakdown, simply because the number of "spf2.0"
> records is miniscule by comparison to the rest.

Yes, but when presenting data, as in a scientifc paper, you need to be
precise, so that an independent 3rd party could in principle repeat
the measurement and the analysis. That's my problem with the existing
tables.

> So really we need to compare the use of the two RRTYPEs and the use of the
> two protocols independent of the RRTYPEs, since SPF only cared about TXT
> and SIDF could use either.
> 
> Pete suggests having two tables for each survey: (a) a comparison of
> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE.  Would
> that be sufficient?

Yes, I think that would be much better. I haven't seen Pete's comment
but it sounds as if I would agree with it :-)

   Brian

> 
> 
>>> It's possible that some of these are always zero but there is no way for
>>> a reader
>>> to tell. This relates to the breakage in the SPF transition plan that the
>>> draft
>>> points out (Appendix A, bullet 4).
>>>
>> Major issues:
>>
>>
>> There was a significant comment about Section 3.1 during the AD
>> evaluation.  I'll leave it to Murray to get me the modified text to address
>> this review. :-)
>>
> 
> Right; Pete had roughly the same question but he hasn't asked it on the
> spfbis list yet.  His suggestion is now above, for the record.  :-)
> 
> 
>>  Finally, in Appendix A we find:
>>>  "Fortunately in the intervening time, the requirements for new RRTYPE
>>>   assignments was changed to Expert Review, and the posture has become
>>>   more relaxed."
>>>
>>> This is slightly inaccurate. Actually the policy has been changed to
>>> RFC6195, which is a modified form of Expert Review. I suggest something
>>> less opinionated:
>>>
>>>   Fortunately in the intervening time, the requirements for new RRTYPE
>>>   assignments was changed to be less stringent [RFC6195].
>>>
> OK.
> 
> 
>>> Nits
>>> ----
>>>
>>> "9.1.  Normative References
>>>
>>>   [DNS]      Mockapetris, P., "Domain names - implementation and
>>>              specification", STD 13, RFC 1035, November 1987.
>>>
>>>   [PRA]      Lyon, J., "Purported Responsible Address in E-Mail
>>>              Messages", RFC 4407, April 2006."
>>>
>>> Firstly, it's quite inconvenient having references like this
>>> instead of [RFC1035] etc.
>>>
>> I'll leave it to Andrew to come up with the change to address this. :-)
>>
> 
> I concur with Andrew that this is a stylistic choice.  I find the mnemonic
> method in use easier to read.
> 
> 
>>  Secondly, it doesn't seem right to have Experimental RFCs listed
>>> as normative references. In fact, since this draft is not a technical
>>> specification, I'm not sure it needs to have the Normative/Informative
>>> split at all.
>>>
>> There were some comments about the normative references (see summary at
>> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01505.html ).
>>  I'll use that as input for the answer if there aren't any comments.
>>
> 
> I concur with Barry's reply to this point.
> 
> -MSK
>