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

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jun 2012 08:30:49 -0700

At 03:36 06-06-2012, Brian E Carpenter wrote:
>Please see attached review.

>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive.
>
>Document: draft-ietf-spfbis-experiment-09.txt
>Reviewer: Brian Carpenter
>Review Date: 2012-06-06
>IETF LC End Date: 2012-06-09
>IESG Telechat date:
>
>Summary:  Almost ready
>--------
>
>Comment:
>--------
>
>I think the Conclusions and Appendix A are almost entirely correct.
>
>Major issues:
>-------------
>
>IMHO section 3.1 needs several clarifications:
>
>"These surveys selected substantial sets of distinct domain names..."
>
>Were these exclusively domain names with MX records?
>
>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".
>
>Does "TXT replies" mean *any* kind of TXT record, or only TXT records that
>start with "v=spf"?
>
>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.)
>
>At the moment I can't fully understand the significance of the results.
>
>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
>
>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).

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. :-)

>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].
>
>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. :-)

>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.

If anyone has any comments about the above, please post them to the 
SPFBIS mailing list.

Regards,
S. Moonesamy (as document shepherd)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2012 11:53:21 -0400

> I'll leave it to Andrew to come up with the change to address this. :-)

This isn't a change anyone needs to make, it's a style complaint.  The
editors preferred to use the symbolic-reference style, and the
reviewer prefers the RFC-named style.  I also personally prefer the
latter, but the RFC Editor doesn't have a rule, and I am not willing
to run roughshod over historical freedoms that WG document editors have.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jun 2012 15:23:06 -0400

Leaving the entire message below, because Brian doesn't appear to have been
copied on it.  But I just want to respond to one bit:

>> 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.
>
> 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 don't see why it's not right at all, and please don't make the mistake of
thinking that an informational document doesn't have normative references.
 I think the original Experimental docs are *absolutely* normative
references for this document, and i see nothing wrong with that at all.

Barry

On Wednesday, June 6, 2012, S Moonesamy wrote:

>> <http://wiki.tools.ietf.org/**area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-spfbis-experiment-**09.txt
>>    "+------------------+---------**--+-------+
>>     +------------------+----------**-+-------+"
>>
>> 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
> evaluation.  I'll leave it to Murray to get me the modified text to address
> this review. :-)
>
> 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.
>
> If anyone has any comments about the above, please post them to the SPFBIS
> mailing list.
>
> Regards,
> ______________________________**_________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/spfbis
>

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jun 2012 12:43:18 -0700

Hi Barry,
At 12:23 06-06-2012, Barry Leiba wrote:
>Leaving the entire message below, because Brian doesn't appear to 
>have been copied on it.

I didn't copy Brian as I thought it better to wait for a WG reply.

>I don't see why it's not right at all, and please don't make the 
>mistake of thinking that an informational document doesn't have 
>normative references.  I think the original Experimental docs are 
>*absolutely* normative references for this document, and i see 
>nothing wrong with that at all.

The comment posted by Dave is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html

I generally use the following for guidance:

   "Normative references specify documents that must be read to
    understand or implement the technology in the new RFC, or
    whose technology must be present for the technology in the
    new RFC to work."

Regards
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jun 2012 21:50:48 -0700

Is that an important thing to state?  I don't believe it is.  They're
domain names seen on incoming email in some way.

>> Also in section 3.1 there are several tables like:
The section is discussing RRTYPEs, so TXT refers to TXT RRTYPEs (type 16)
and SPF refers to SPF RRTYPEs (type 99).

>> Does "TXT replies" mean *any* kind of TXT record, or only TXT records that
That's a fair question.  I'll update the draft accordingly.

>> 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.

>> 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.

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?

> evaluation.  I'll leave it to Murray to get me the modified text to address

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.  :-)

>>   assignments was changed to be less stringent [RFC6195].
OK.

> 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.

>  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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jun 2012 22:28:40 -0700

Hi Brian,
>Please see attached review.

Thanks for the review.

>I think the Conclusions and Appendix A are almost entirely correct.

They're domain names seen on incoming email in some way.  Murray 
doesn't believe that it is important to state that.  If you think it 
is important, let me know.

>Also in section 3.1 there are several tables like:

It's a fair question.  The draft will be updated to fix that.

>FQDNs? If so, are they identical? (Presumably they should be.)

Yes to the first question.  The working group didn't evaluate the second.

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?

This is slightly inaccurate.  Actually the policy has been changed to 
RFC6195, which is a modified form of Expert Review. Murray suggests 
something less opinionated:

>instead of [RFC1035] etc.

Here's Andrew's response as WG Chair:  This isn't a change anyone 
needs to make, it's a style complaint.  The editor preferred to use 
the symbolic-reference style, and the reviewer prefers the RFC-named 
style.  He also personally prefer the latter, but the RFC Editor 
doesn't have a rule.

Murray finds the mnemonic method in use easier to read.

>specification, I'm not sure it needs to have the Normative/Informative

Dave Crocker and Barry Leiba had an discussion about "normative 
references" at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html.

Even though the draft is not a technical specification, it is 
important that the reader reads the RFCs listed as normative to 
understand the draft.  The Experimental RFCs are not even a downward 
reference in this case as this draft is not being published on the 
Standards Track.

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jun 2012 08:26:26 +0100

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

See below...

On 2012-06-06 20:43, S Moonesamy wrote:
>> Leaving the entire message below, because Brian doesn't appear to have
>> been copied on it.
> 
>> *absolutely* normative references for this document, and i see nothing
>> wrong with that at all.
> 

Exactly. This draft does not define new technology, is not a
technical specification (cf RFC 2026), and therefore does not
need normative references.

    Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jun 2012 08:35:12 +0100

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-masked]>
> 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-masked]>
> Cc: [email-masked], [email-masked]
> 
> 

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

> 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.

> 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.

> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE.  Would

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

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2012 03:58:37 -0400

S Moonesamy wrote:

>> Brian Carpenter wrote:
>> 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
> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE.  
> Would that be sufficient?

I don't see where this is headed. The report was looking for something 
that was already there and know and I guess it trying to get a 
justification to eliminate something.

What are we looking for?

   Elimination of SPF RR lookups?
   Elimination of SPF2.0 content in the SPF or TXT records?

I hate to revert back to the original design presumptions in MARID, 
but everyone was working on the basis that one day DNS servers, ALL OF 
THEM, CROSS THE OS BOARD, would inevitably be updated to support 
RFC3597 Handling of Unknown DNS Resource Record (RR) Types.  But that 
has not been the case, MS DNS 5.0 was only updated to support SVR, 
DNSSEC. But not the passthru query recursive requirements necessary 
for RFC3597.

So supporting any unnamed RR type is simply not practical today. 
However, as predicted, the migration advice did materialize, abeit in 
short numbers.  So IMO, we need to make a decision if its still 
feasible to pursue unnamed RR type support.

Second and finally, the results of SPF2.0 record is irrelevant because 
this REPORT is not doing anything towards or does it have any business 
in eliminating or providing the "illusion" of eliminating Sender ID or 
SIDF (Sender ID Framework) which includes PRA and SUBMITTER protocol 
support.

This Report has failed to consider the original EXPERIMENTAL questions 
of the so call conflicts that were cited, ones I have failed to see 
since its inception in early 2000s.

Address the real technical issues so that deployments of many years 
can learn what do  do with the mix support of SPF vs SIDF and also TXT 
vs SPF RRs.  The data in this report has not provided any engineering 
insight whatsoever other than the fact that clients DO support both 
SIDF and SPF RRs.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jun 2012 02:21:49 -0700

Hi Hector,

[Gen-ART removed from Cc as this not a Gen-ART issue in my opinion]

At 00:58 07-06-2012, Hector Santos wrote:
>I don't see where this is headed. The report was looking for 
>something that was already there and know and I guess it trying to 
>get a justification to eliminate something.

The Responsible Area Director performed an evaluation of the 
draft.  As the question was something which could be resolved, I 
suggested that to proceed with the Last Call.  Any proposed changes 
will be brought to the attention of the SPFBIS WG for comment.  I 
suggest waiting for the actual text before starting the discussion.

>but everyone was working on the basis that one day DNS servers, ALL 
>OF THEM, CROSS THE OS BOARD, would inevitably be updated to support 
>RFC3597 Handling of Unknown DNS Resource Record (RR) Types.  But 
>that has not been the case, MS DNS 5.0 was only updated to support 
>SVR, DNSSEC. But not the passthru query recursive requirements 
>necessary for RFC3597.
>
>However, as predicted, the migration advice did materialize, abeit 
>in short numbers.  So IMO, we need to make a decision if its still 
>Second and finally, the results of SPF2.0 record is irrelevant 
>because this REPORT is not doing anything towards or does it have 
>any business in eliminating or providing the "illusion" of 
>eliminating Sender ID or SIDF (Sender ID Framework) which includes 
>PRA and SUBMITTER protocol support.
>
>This Report has failed to consider the original EXPERIMENTAL 
>questions of the so call conflicts that were cited, ones I have 
>failed to see since its inception in early 2000s.
>
>can learn what do  do with the mix support of SPF vs SIDF and also 
>TXT vs SPF RRs.  The data in this report has not provided any 
>engineering insight whatsoever other than the fact that clients DO 
>support both SIDF and SPF RRs.

The message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01520.html was 
posted as a WGLC comment.  I read it as meaning that "it works for 
you".  I cannot tell from the above which part of 
draft-ietf-spfbis-experiment-09 is an issue for you.  I suggest that 
you comment on specific text from draft-ietf-spfbis-experiment-09 if 
you would like to recommend any change as part of the Last 
Call.  Please note that the Last Call ends on June 9, 2012.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2012 05:39:51 -0400

> method in use easier to read.

For what it's worth, I find the most useful citations to be ones that BOTH
tell me what the document is and how to find it, without requiring me to go
to the references.  For instance, up in Section 2:

   The term "RRTPYE" is used to refer to a Domain Name System ([DNS])
   Resource Record (RR) type.

I think this is more convenient for readers:

   The term "RRTPYE" is used to refer to a Domain Name System [RFC1035]
   Resource Record (RR) type.

... because it already tells me that it's about DNS, and adding the RFC
number is useful.  This is more obvious when you talk about, say, PRA.
Suppose we had a citation to PRA at the beginning of Section 3.3, using
your style:

   The [PRA] is the output of a heuristic (...etc...)

Compare with this:

   The Purported Responsible Address [RFC4407] is the output (...etc...)

Or even with this:

   The PRA [RFC4407] is the output (...etc...)

That tells me both WHAT it is (PRA) *and* WHERE to find it (RFC 4407).

But none of this is blocking; if you want to use the style you're using, as
Andrew says, the RFC Editor does not force a style that changes that. Maybe
you have a good reason to disagree with what I'm saying here.  And this is,
in any case, not the place to have a lengthy discussion about it.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jun 2012 14:28:06 +0100

On 2012-06-07 08:58, Hector Santos wrote:
>>> 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

I am looking for clear presentation of the observed data, nothing more,
as I do whenever I read a data-based document. As my review stated,
I have no problem with the conclusions drawn in the draft.

   Brian

> I hate to revert back to the original design presumptions in MARID, but
> everyone was working on the basis that one day DNS servers, ALL OF THEM,
> CROSS THE OS BOARD, would inevitably be updated to support RFC3597
> Handling of Unknown DNS Resource Record (RR) Types.  But that has not
> been the case, MS DNS 5.0 was only updated to support SVR, DNSSEC. But
> not the passthru query recursive requirements necessary for RFC3597.
> 
> short numbers.  So IMO, we need to make a decision if its still feasible
> to pursue unnamed RR type support.
> 
> Address the real technical issues so that deployments of many years can
> learn what do  do with the mix support of SPF vs SIDF and also TXT vs
> SPF RRs.  The data in this report has not provided any engineering
> insight whatsoever other than the fact that clients DO support both SIDF
> and SPF RRs.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Jun 2012 18:41:04 +0200

Ooops, re-posting...

On Thu 07/Jun/2012 07:28:40 +0200 S Moonesamy wrote:

>> 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.)
> 

Actually, Philip evaluated the second question as well, mentioning
that some 17% of type99 records differ from the corresponding type16.
http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html

FWIW, I repeated a similar test for 24,853 domains in the DNSWL list,
and found that only 3% of the 587 domains that use both types had such
difference.

---

From: Pete Resnick <[email-masked]>
Date: Sat, 9 Jun 2012 10:29:34 -0500

Brian,

> I have no problem with the conclusions drawn in the draft.

I'm afraid you got distracted by Hector's question and didn't answer 
SM's. Please do.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jun 2012 16:35:30 +0100

Hi Pete,

> I'm afraid you got distracted by Hector's question and didn't answer

Sorry - yes, I think those two tables would be fine.

    Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jun 2012 14:14:18 -0700

I have a revised version with the requested changes stuck in submission
tool limbo.  I'll get it posted as soon as the Secretariat can fix it.

-MSK

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2012 08:36:32 +0100

I've looked at the changes in the -10 version, and it's
much clearer to me, thanks. If I'm asked to review it again
it will be "Ready".

Regards
   Brian