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 <[email protected]> > 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 <[email protected]> > Cc: [email protected], [email protected] > > > On Wed, Jun 6, 2012 at 8:30 AM, S Moonesamy <[email protected]> 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
