Subject: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08

From: S Moonesamy <[email-masked]>
Date: Fri, 11 May 2012 16:02:36 -0700

Hello,

Here's my review as Document Shepherd.  I am copying it to the 
mailing list as WG information.

Summary: The document is almost ready for publication as an 
Informational RFC but has a few issues that should be fixed before publication.

The document is well-written and it provides evidence about the SPF 
and Sender ID experiments and conclusions in Section 5.  If this was 
not a best effort by the working group, I would have ask for some of 
the text in Appendix A to be backed by facts.

The question of the status of the RFCs may be raised during the Last 
Call.  I don't consider it as an issue based on the SPFBIS WG 
discussions.  I suggest waiting for the review from the Responsible 
Area Director instead of getting into a discussion about an issue 
which may turn out to be a non-issue.

The discussion in Appendix A about "pressure" might cause some 
controversy.  As there is WG consensus on the draft, I won't suggest 
any change.  The "DNS experts within the community that will 
undoubtedly" comment may also be controversial.  I note that 
draft-schlitt-spf-classic-02 was the draft approved by the 
IESG.  I'll suggest waiting for AD review.

I'll wait for the document to address the review.

Minor issues:

In Section 5:

   "2. Of the records retrieved, fewer than 3% included specific
       requests for processing of messages using the PRA algorithm,
       which is an essential part of Sender ID."

The first point is about "DNS resource record".  It is not clear what 
"records retrieved" are in the above.  I am listing this as minor due 
to text clarity; it could have been filed as a nit.

   "3.  Although the two mechanisms often used different email address
        fields as the subject being evaluated, no data collected showed
        any substantial operational benefit, in terms of improved
        accuracy, to using one mechanism over the other."

What mechanisms does the above refer to?

   "6.  Ample options are available in terms of software to implement
        either of the two protocols."

I'll suggest:

   "multiple implementations of either of the two protocols are available."

 From an IETF perspective, software is the implementation of a protocol.

Nits:

In Section 3.3:

   "The PRA is the output of a heuristic that seeks to scan a message"

I suggest expanding on first use.

    "An unknown number of SMTP clients implement SUBMITTER."

I suggest adding "SMTP extension" at the end of the sentence.

   "Although there is substantial activity showing its use in MTA logs,
    it is not possible to determine whether they are multiple instances
    of the same client, or separate client implementations."

I'll suggest:

    Although information from MTA logs indicate substantial use of the SMTP
    extension, it is not possible to determine whether the usage is 
from multiple
    instances of the same SMTP client or different SMTP client implementations.

   "An active survey was done of running and publicly reachable MTAs."

Sugested:

   An active survey of MTAs accessible over the Internet was performed.

  "The MTAs selected were found by querying for MX and A records of a"

Suggested: resource records

In Section 5, point 4: implementations

   "Later, after RRTYPE 99 was assigned (long after IESG approval of the
    document, in fact)"

It's not clear what the document is in the above.

Regards
S. Moonesamy (as document shepherd)

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 11 May 2012 19:07:42 -0400

> It's not clear what the document is in the above.

draft-schlitt-spf-classic-02

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 May 2012 23:11:49 +0000

> -----Original Message-----
> From: S Moonesamy [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 3:57 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Document shepherd review of draft-ietf-spfbis-experiment-08
> 
> Hello,
> 
> Here's my review as Document Shepherd.  I am copying it to the mailing 
> list as WG information.
> 

I claim everything in Appendix A is factual.  Certainly much of it is anecdotal, but there are enough people participating in this working group that were also around for the earlier work, and the MXCOMP and spf-discuss list archives are available as references, that it can all be "proven" if needed.  That it has WG consensus means to me that we feel it is an accurate reflection of the relevant history.

I suggest we leave it as-is, and respond by including specific links to list archives and such if challenged during IETF Last Call or IESG Evaluation.

> which may turn out to be a non-issue.

I propose we allow that discussion to happen independent of the working group as much as possible, and allow the IESG to make that ultimate determination.  They might, in fact, decide they want to do that on their own even if it doesn't come up during IETF Last Call.  Or there could be an individual request to do so.

> draft-schlitt-spf-classic-02 was the draft approved by the IESG.  I'll 
> suggest waiting for AD review.

I concur.

> I'll wait for the document to address the review.

Which document?

> to text clarity; it could have been filed as a nit.

It could say "DNS records" to be precise, but I'd also point out that the DNS records were the only record retrievals done during any of the data collection described in the earlier sections.

> What mechanisms does the above refer to?

SPF and Sender ID.  "Protocols" might be better.

> From an IETF perspective, software is the implementation of a 

I think I prefer "ample", as it is descriptive of the fact that there were enough of them that any reasonable operator had the option to find support for one protocol or the other.  "Multiple" could mean "two", and there were actually several more than that in each case.

> I suggest expanding on first use.

Agree.

> I suggest adding "SMTP extension" at the end of the sentence.

I think that's redundant to the second paragraph, but sure.

>     instances of the same SMTP client or different SMTP client 

OK.

>    An active survey of MTAs accessible over the Internet was performed.

OK.

> Suggested: resource records

OK.

> It's not clear what the document is in the above.

RFC4408.  We can change that.

Would you like an -09, or should we handle these during IETF Last Call, since they are minor?

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 May 2012 16:41:52 -0700

Hi Murray,
At 16:11 11-05-2012, Murray S. Kucherawy wrote:
>I claim everything in Appendix A is factual.  Certainly much of it 
>is anecdotal, but there are enough people participating in this 
>working group that were also around for the earlier work, and the 
>MXCOMP and spf-discuss list archives are available as references, 
>that it can all be "proven" if needed.  That it has WG consensus 
>means to me that we feel it is an accurate reflection of the relevant history.

Ok.

>I suggest we leave it as-is, and respond by including specific links 
>to list archives and such if challenged during IETF Last Call or 
>IESG Evaluation.

I'll suggest not to make waves. :-)  My task is to help the working 
group and other parties resolve any issue raised during the Last Call 
and the IESG Evaluation.

>I propose we allow that discussion to happen independent of the 
>working group as much as possible, and allow the IESG to make that 
>ultimate determination.  They might, in fact, decide they want to do 
>that on their own even if it doesn't come up during IETF Last 
>Call.  Or there could be an individual request to do so.

Yes.

>Which document?

I noticed that I left out editor after sending the message.

>It could say "DNS records" to be precise, but I'd also point out 
>that the DNS records were the only record retrievals done during any 
>of the data collection described in the earlier sections.

I'll leave it to you as it is an editorial nit.

>SPF and Sender ID.  "Protocols" might be better.

Ok.

>I think I prefer "ample", as it is descriptive of the fact that 
>there were enough of them that any reasonable operator had the 
>option to find support for one protocol or the other.  "Multiple" 
>could mean "two", and there were actually several more than that in each case.

Ok.

>I think that's redundant to the second paragraph, but sure.

Ok.

>RFC4408.  We can change that.

Here's what you have in -09:

   "Later, after RRTYPE 99 was assigned (long after IESG approval of
    [SPF], in fact)"

It's actually incorrect.  As this is in the Appendix, I'll just put 
it to an editorial comment.

>Call, since they are minor?

I read -09.  I consider the comments as addressed.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 May 2012 23:47:02 +0000

> Sent: Friday, May 11, 2012 4:42 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08
> 
> It's actually incorrect.  As this is in the Appendix, I'll just put it
> to an editorial comment.

Would you prefer "the draft that became [SPF]"?

Anyway, I think we can deal with that in IETF LC.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 May 2012 18:02:46 -0700

Hi Murray,
>Would you prefer "the draft that became [SPF]"?

I'll have to give this some more thought.

>Anyway, I think we can deal with that in IETF LC.

I would leave this nit for IETF Last Call or even later.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 May 2012 23:15:11 -0400

> discussions.  I suggest waiting for the review from the Responsible Area 
> Director instead of getting into a discussion about an issue which may 
> turn out to be a non-issue.
> 
> controversy.  As there is WG consensus on the draft, I won't suggest any 
> change.  The "DNS experts within the community that will undoubtedly" 
> comment may also be controversial.

I have a question.

Are we pass the point that the SPFBIS can be endorsed as Proposed 
Standard without its special RRTYPE?

Background:

I think I was among those here that advocated continued SPF special RR 
TYPE (type99) support because:

    a) Surprisingly, evidence presented here showed support or it was
       enabled.  Our implementation has it OFF by default because of
       the #1 reason - SPF already had a very high DNS overhead and
       waste in blind queries of domains.

    b) The early desires to use new RRTYPEs with the coupled expectations
       DNS Servers will evolved to support RFC3597 unnamed RRTYPEs.

    c) To help with the IETF endorsement of already questionable
       protocol surely to have a high DNS overhead and waste (NXDOMAIN)
       in queries.

I didn't think SPF was IETF material before MARID, the same way I 
didn't think Greylisting was IETF material.  No one in the SMTP and 
DNS community would support
these ideas which were considered by many as KLUDGE solutions. Just 
consider many of the same people here (and in IETF-SMTP) were 
vehemently against both of these new ideas, and today, you will many 
supporting them today as IETF material.

So to me, it was always about the "IETF Endorsement" value and while 
text in the appendix could be considered part of the facts, it was 
more about make SPF "IETF endorsement" material. The "pressure" was 
not just DNS people, but most, if not all, involved as early adopters 
of all these new DNS based applications using TXT records.  What 
really highlighted the concern was Microsoft's introduction of CEP, 
the XML-formatted version of SPF.  To me, it showed the changing 
mindset of Application Developers with little or lesser concerns with 
system level scaled designs.  XML for DNS TXT records?  You got to be 
kidding me! It was already to use TXT records and no way the IETF/DNS 
people would accept XML on that of that!  It was the first thing that 
had to go if we can get the IETF/DNS to even consider SPF for endorsement!

But times has changed, just look at the IETF work for GreyListing! No 
way, did you even dare bring that up in 2003. Outside of SPF, today we 
have other DNS applications as proposed standards or standard track 
all as TXT-only support:

   Proposed standards with DNS TXT-ONLY requirement

   DKIM
   VBR
   ADSP
   ATPS

and even new ones like DMARK that even adds more DNS redundancy and 
waste, and without a doubt more complex in application design support!

So if these protocols were endorsed as IETF proposed standard RFCs, 
which might suggest the DNS concerns are lesser today for many other 
reasons like faster hardware, higher I/O bandwidth and more reliable, 
robust DNS servers, then SPF no longer has the same IETF endorsement 
considerations using RRTYPES as it did back in 2004-2006.

This was all why I felt it was necessary to ask these questions in the 
IETF and DNS-OPS list, to see what the IETF/DNS community mindset is 
today.

 From all the responses I saw in these threads, I came out with the 
general view that it was be "NICE" to have RRTYPE type for DNS 
applications, but either because the practical reality of not having a 
wide cross section of compatible DNS servers in all OSes, not just 
*nix  systems, the Domain Hosting Web Managers don't support unnamed 
types entries, and/or the current performance and operations of DNS is 
so much better today, the overhead associated with all these DNS TXT 
lookups is a lesser concern, making TXT records acceptable by the IETF 
for proposed standards.

So if we are pass the IETF endorsement quality of the question for no 
longer requiring a RRTYPE in order to get a proposed standard, then I 
think the report should recommend dropping support for type99 in 
RFC4408BIS for the following reasons:

   - No longer required for IETF endorsement,

   - Other IETF proposed standards exist for DNS TXT only records,

   - Lack of wide DNS servers supporting RFC3597 on all OS platforms
     with no short or near term expectation this will change, and

   - Removing type99 will lower DNS overhead of dual type lookups.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Sat, 12 May 2012 00:39:34 -0700

Hi Hector,
>Standard without its special RRTYPE?

At the end of the discussions relating to Issue #9, the WG Chair 
mentioned the following:

   "that the document will say SHOULD NOT publish RRTYPE 99 and MUST
    NOT query RRTYPE 99."

When it comes to a draft, the IETF is only past a point when it is 
published as a RFC.  The SPFBIS working group is past the point on 
Issue #9 (SPF RR Type and TXT RR).  A working group participant may 
raise an issue if there is new information available; i.e. 
information which was not considered when the issue was discussed.

>This was all why I felt it was necessary to ask these questions in 
>the IETF and DNS-OPS list, to see what the IETF/DNS community mindset is today.

There will be an IETF Last Call on 
draft-ietf-spfbis-experiment-09.  There will be an IETF Last Call for 
4408bis.  Comments will be solicited from the IETF Community.  I 
don't see any reason to ask the DNS Community a question as it is not 
like the working group is updating a DNS specifications or taking on 
new work which has an impact on DNS.  There are some participants 
from the DNS Community which are aware of the work being done in this 
working group.  They also have the opportunity to comment during the 
IETF Last Calls.

> applications, but either because the practical

I performed an individual review of draft-ietf-spfbis-experiment-09 
as Document Shepherd. The questions I asked were addressed.  I did 
not raise the RRTYPE issue as it has been widely discussed by the 
working group and I didn't find anything new which would be useful 
input to the discussion.

>So if we are pass the IETF endorsement quality of the question for 
>no longer requiring a RRTYPE in order to get a proposed standard, 
>then I think the report should recommend dropping support for type99 
>in RFC4408BIS for the following reasons:
>

I read the message posted on 9 May, 2012 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01520.html ) 
and all the other messages which have been posted during the 
WGLC.  My conclusion is that nobody has threatened an appeal or 
otherwise indicated extreme discontent during the WGLC.

If there are any areas of conflict, e.g. a WG participant threatened 
an appeal or is unhappy about an issue, I can add that to the 
write-up.  If I have missed something, let me know.  RFC 4858 
provides information about document shepherding.  The task is to help 
with IETF process details and to help the working group address any 
future issue raised outside the working group.

I encourage a WG participant to discuss any significant issue within 
the working group.  If anyone believes that the working group did not 
give careful consideration to an issue, I'll bring it to the 
attention of the Responsible AD.  I would appreciate if such issues 
are accompanied by an explanation as the Responsible AD will ask me 
to explain the problem clearly.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 May 2012 12:10:50 +0200

On Sat 12/May/2012 11:19:12 +0200 S Moonesamy wrote:
> and all the other messages which have been posted during the WGLC.  My
> conclusion is that nobody has threatened an appeal or otherwise
> indicated extreme discontent during the WGLC.

As far as RRTYPE 99 is concerned, it seems to me we're all happy to
remove such cumbersomeness --at least, I am.  I guess most of us will
be even more happy when SPF will be able to drop RRTYPE 16 and use its
own type in a well defined and supported manner.  IMHO, Appendix A
expresses such feeling quite directly.

> write-up.  If I have missed something, let me know.  RFC 4858 provides
> information about document shepherding.  The task is to help with IETF
> process details and to help the working group address any future issue
> raised outside the working group.

To stay on the safe side, the third paragraph of the Introduction
should read:

   In line with the IESG's request to evaluate after a period of time,
   this document concludes the experiments and presents evidence
   regarding a deployment feature and comparative effects of the two
   protocols.  At the end it presents conclusions based on the data
   collected.

> the working group.

There are significant issues that are being moderated out, so I'd
better not do so.  I assume there is plenty of good reasons to keep
those issues open at this stage.  Nevertheless, it wouldn't be correct
to pretend they're closed.

I've already cited [Ned]:

   I think mitigation strategies for the issues SPF causes are highly
   relevant to the question of whether or not SPF should be placed on
   the standards track.

But that's not relevant to the document at hand.

-- 
[Ned]
http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-smtp&i=01OF6HRP963S0006TF%40mauve.mrochek.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 May 2012 04:41:20 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, May 12, 2012 3:11 AM
> To: [email-masked]

I think I agree with all of that, although if the same issues exist when we eventually consider moving some future version of SPF to its own RRTYPE, I think we'll have the same trepidation.  The bar to getting an RRTYPE assigned is (I'm told) substantially lower, but getting things like provisioning tools to adapt has to get simpler.  The whole field has to get better for new RRTYPEs before that's a viable solution.

> to pretend they're closed.

Let's be careful not to mix "keeping focus" with "moderation".

Nobody's "pretending" that the issues I know you're referring to are closed.  This is simply the wrong place to discuss them.

> But that's not relevant to the document at hand.

Right.

-MSK