Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-experiment-09

From: S Moonesamy <[email-masked]>
Date: Sun, 13 May 2012 11:24:14 -0700

Hi Alexey,
At 10:36 13-05-2012, Alexey Melnikov wrote:
>I have been selected as the Applications Area Directorate reviewer 
>for this draft (for background on appsdir, please see

[snip]

>Summary:  This draft is ready for publication as an Informational document.

Thanks for the review.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Sun, 13 May 2012 17:46:14 -0700

Hi Martin,

Thanks for the feedback.  I am forwarding it to SPFBIS.

Regards,
S. Moonesamy (as document shepherd)

At 17:39 13-05-2012, Martin J. Dürst wrote:
>Sorry to just use this review to piggyback a 
>comment that I wanted to make for a while:
>
>It would be very good if the abstract could 
>include a summary of the document, not (only) an 
>introduction to the history (two paragraphs) and 
>a meta-summary of what it contains (paragraph copied below).
>
>    After six years, sufficient experience and evidence have been
>    collected that the experiments thus created can be considered
>    concluded.  This document presents those findings.
>
>If I understand 
>http://tools.ietf.org/html/draft-ietf-spfbis-experiment-09#section-6 
>correctly, this could be done e.g. by changing the above paragraph to:
>
>    After six years, sufficient experience and evidence have been
>    collected that the experiments thus created can be considered
>    concluded.  This document finds that SPF has widespread
>    implementation and deployment, comparable to many standards
>    track protocols, but that there is an absence of significant
>    adoption for Sender ID.
>
>This is just a first try; I'd personally favor 
>to cut down the history part of the abstract and 
>add more details to the conclusion part if possible.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 May 2012 05:45:47 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Sunday, May 13, 2012 5:46 PM
> To: "Martin J. Dürst"
> Cc: [email-masked]
> Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09
> 
> >It would be very good if the abstract could include a summary of the
> >document, not (only) an introduction to the history (two paragraphs)
> >and a meta-summary of what it contains (paragraph copied below).
> >
> >This is just a first try; I'd personally favor to cut down the history
> >part of the abstract and add more details to the conclusion part if
> >possible.

I don't have any particular objection except that we shouldn't change it at this point unless we get AD direction to do so.  Consensus and all that.  :-)

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 May 2012 01:50:45 -0400

>>    track protocols, but that there is an absence of significant

Maybe I never mastered my English, but I don't I follow this, nor does 
it match my understand on what a protocol should be.

-1

The experimental questions and expressed concerns have not been 
adequately reviewed in this report.  Its uses a "deployment" criteria 
which does not adequately address the original expectations questions 
and concerns and is not sufficient to judge anything, in my production 
and field experience. i.e. this report provides me no justification to 
"drop" SUBMITTER support, and I am concern that just an abstract 
written as above expressed the notion that is it "OK" to drop support.

Even if one wishes to use a triage concept, just look at hotmail.com - 
it ignores RFC4408 -ALL publications and is appears to be just work 
with sender-id in its operation and with AUTH-RES reporting. Nothing 
SPF related is shown, not even Received-SPF.

Until an adequate protocol technical review of both protocols as 
expected by the original IESG 2006 expectations and concerns, this 
report can not make any judgments on SENDER-ID, nor SUBMITTER.  Far 
too many clients support these protocols.

This SPFBIS effort can only promote SPF RFC4408 only to PS 
considerations and can do so without judging SENDER-ID which I see no 
adequate data to make any decision.

The experiment which amounts to the integration issues of the 
protocols, in my view, is not concluded.

For the record, we don't implement SENDER-ID, but we support 
SUBMITTER. The fact we continue to see significant usage of SUBMITTER 
is evidence that SENDER-ID is in play by many clients.

-- 
HLS

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 May 2012 15:25:32 +0900

Hello Hector,

I'm sorry if I got the summary wrong. But what I wanted to stress is 
that there should be a summary of the conclusions of the document, not 
only a summary of the history that lead to this document.

Regards,    Martin.

On 2012/05/14 14:50, Hector Santos wrote:
> "drop" SUBMITTER support, and I am concern that just an abstract written
> as above expressed the notion that is it "OK" to drop support.
>
> it ignores RFC4408 -ALL publications and is appears to be just work with
> sender-id in its operation and with AUTH-RES reporting. Nothing SPF
> related is shown, not even Received-SPF.
>
> report can not make any judgments on SENDER-ID, nor SUBMITTER. Far too
> many clients support these protocols.
>
> The experiment which amounts to the integration issues of the protocols,
> in my view, is not concluded.
>
> For the record, we don't implement SENDER-ID, but we support SUBMITTER.
> The fact we continue to see significant usage of SUBMITTER is evidence
> that SENDER-ID is in play by many clients.
>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 May 2012 00:16:23 -0700

At 22:45 13-05-2012, Murray S. Kucherawy wrote:
>I don't have any particular objection except that we shouldn't 
>change it at this point unless we get AD direction to do 
>so.  Consensus and all that.  :-)

Ok. :-)

I am copying this message to apps-discuss@ in case anyone from that 
mailing list wishes to follow up on the AppsDir review about 
draft-ietf-spfbis-experiment-09.  The reviews (including Gen-ART and 
SecDir) and comments will be processed as part of the Last Call comments.

Please note that the document shepherd write-up may be updated with 
the following text being added to the Working Group Summary:

   Some participants were unhappy with the document's incomplete
   coverage of the history of the four Experimental documents and the
   controversies surrounding them.  In the end, working group consensus was
   for factual reporting.  Historical completeness is not the goal of this
   document.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 May 2012 16:05:05 +0200

Hi SM,

>   for factual reporting.  Historical completeness is not the goal of this

For a fair update, I'd rather remove references to history, unless you
refer to the history that lead to this document.  I and others have
indicated a (not extreme) discontent for not covering some deployment
aspects, which cannot be considered historical albeit they used to be
upheld more vigorously in historical times.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 May 2012 08:33:30 -0700

>upheld more vigorously in historical times.

It is up to the document shepherd, with the consent of the 
Responsible Area Director, to determine what goes into the 
write-up.  Based on feedback from two persons, it is easier for me to 
drop the suggested change to the write-up.

BTW, the "discontent" is not in the write-up as it was not apparent 
from the WGLC comments.  I'll send a note to the Responsible Area 
Director about that.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 May 2012 16:40:54 +0000

[removing apps-discuss from this thread]

> Sent: Monday, May 14, 2012 8:34 AM
> To: [email-masked]; [email-masked]
> It is up to the document shepherd, with the consent of the Responsible
> Area Director, to determine what goes into the write-up.  Based on
> feedback from two persons, it is easier for me to drop the suggested
> change to the write-up.
> 

I don't see the distinction between "history" and "the history that led to this document".  Please elaborate.

I also have yet to see any valid argument for why the discussed "deployment aspects" have anything to do with answering the basic question, "Which one have people deployed?", which is the focus of this document.

A treatise on the differences between SPF and Sender ID in technical terms might be interesting, but it is not part of our charter.  Maybe someone should start that as an individual submission, even if only to have a focus for all of this energy people seem to have.

Finally, I don't agree with the claim that either the document or the PROTO are not fair representations of either the facts or working group consensus.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2012 13:37:33 -0400

(Just to spfbis; no need to include apps-discuss on this.)

SM says...
> Please note that the document shepherd write-up may be updated with the
> following text being added to the Working Group Summary:
>

Just to be clear about where this came from:
It was I who suggested that SM add this to the writeup, in order to
make it clear to the IESG that the WG did have a discussion about how
much of the history to include here, and that there was not complete
agreement with the result.  I made the suggestion to make sure the
other ADs are aware of this, and that IESG Evaluation doesn't re-hash
some of what was already discussed here.  If other ADs want to bring
the issue up *with* that knowledge, that's for them to decide.

Remember a couple of things:

- The purpose of the shepherd writeup is to make sure that the
document has been properly reviewed and to provide information to the
IESG for use in IESG Evaluation.

- The document shepherd writeup is not subject to working group
consensus.  Quite the opposite, it's the place for the shepherd to
communicate with the ADs, and SHOULD include information that the
shepherd thinks is important, even or especially if the WG isn't in
agreement.

My suggestion to SM about adding that text was just a suggestion, and
he may (and will) do as he pleases with it.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 May 2012 21:11:04 +0200

On Mon 14/May/2012 19:55:15 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of S Moonesamy

I guess the discontent was not apparent because it was not extreme.
Accordingly, it doesn't need to go in the write-up.

I only suggested a slightly shorter but more comprehensive wording.
Namely:

  Some participants were unhappy with the document's incomplete
  coverage of the four Experimental documents and the controversies
  surrounding them.  In the end, working group consensus was for
  factual reporting.  Completeness is not the goal of this document.

Of course, that suggestion is useless in case the write-up won't be
updated.

> I also have yet to see any valid argument for why the discussed
> "deployment aspects" have anything to do with answering the basic
> question, "Which one have people deployed?", which is the focus of
> this document.

There is a possible misunderstanding:  Since completeness is not a
goal, it is legitimate to focus on a specific topic, and other aspects
can be left out.  However, readers may think that completeness was a
goal, since it's not clearly stated otherwise.
See my proposed rewording of the third paragraph of the Introduction
in http://www.ietf.org/mail-archive/web/spfbis/current/msg01538.html
(WGLC was over already, so I was proposing to /read/ that paragraph
that way, not to actually rewrite it.)

I don't think WG documents have to overcautiously prevent any possible
misinterpretation.  A document can omit some aspects without
explaining why, and without implying that omitted aspects are historic.

> Finally, I don't agree with the claim that either the document or
> the PROTO are not fair representations of either the facts or
> working group consensus.

I claimed that describing the discontent as being related to just
historical questions would not be fair.  As long as the Working Group
Summary is not updated, or is updated correctly, I'm fine with it.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 May 2012 13:06:14 -0700

Barry Leiba, who happens to be one of the Applications Area 
Directors, explained how document shepherding works at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01552.html

It is entirely appropriate to blame the document shepherd of 
draft-ietf-spfbis-experiment for not being fair as it will be a 
document shepherd decision.  It is not appropriate to blame anyone 
else for what will end up as the Working Group Summary.

Regards,