Subject: Re: [spfbis] A proposed reorganization

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Oct 2012 12:29:31 -0700

At 13:37 17-09-2012, Murray S. Kucherawy wrote:
>On reviewing the -07 draft I observed that the flow could be improved,
>and that's thus one of the things I tried to do in the proposal.

Could the WG let me know whether the following is an adequate summary 
of the discussion about the proposal?  Please note that this message 
is not about debating about the views that were expressed.  There 
should be ample time during the face-to-face (Jabber for remote 
participants) meeting for that discussion.

Murray Kucherawy mentioned that the specification has however become 
somewhat bloated with documentation of nuance and other text that has 
nothing to do with interoperability, security, or other topics 
critical to defining a protocol and enabling interoperability.  Much 
of that bloat may well have been there in RFC4408 itself, and the 
working group has focused on developing it rather than cleaning it up. [1]

John Leslie mentioned that "we're going 'round in circles largely 
because we have differing opinions on what is protocol and what is 
operational advice." [2]  William Leibzon noted that that such 
re-organization is likely to go against original intent of SPF.  The 
intent was to have it published as a standard document and if part of 
it is split into "informational" type document that is very different 
especially given that SPF was published as experimental standard 
already [3].  Dave Crocker posted the following questions [4]:

  1. Is it generally 'legal' to reorganize a specification document 
during an effort
     like spfbis and specifically legal for spfbis?

  2. Does the existing organization have some issues?

  3. Does the proposed reorganization increase clarity or otherwise improve the
     document?

Scott Kitterman mentioned that the current document (4408) is the 
basis for multiple, interoperable implementations [5].  William 
Leibzon mentioned that the material has been used and understood by 
countless developers [6].  Alessandro Vesely commented that Version 
-07 was still organized according to RFC 4408, with such 
idiosyncrasies as putting macros after Received-SPF rather than along 
with mechanisms and modifiers where they pertain and separating 
filter handling from the result computation is a needed cleanup that 
this reorganization opens nicely [7].  Arthur Thisell commented that 
deciding the order of the macro and received-spf headers is not important [8].

Andrew Sullivan tried to clarify the goals of the discussion about 
the proposed reorganization [9].

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html
9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html

---

From: Franck Martin <[email-masked]>
Date: Tue, 30 Oct 2012 19:39:31 +0000

The question is may be a more fundamental one, considering the original
document was intended to be experimental, the editorial proofing may have
been very relaxed.

Now that the document is on the standard track, it may need to be in par
in format to other standards developed today

So is the document formatted like a standard? Does it need a rewrite to
adopt current editorial practices, and that without changing the protocol?

On 10/30/12 12:29 PM, "S Moonesamy" <[email-masked]> wrote:

>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: Dotzero <[email-masked]>
Date: Tue, 30 Oct 2012 15:42:04 -0400

I think this is an adequate summary of the discussion but would point
out that the requirements for a successful standards track document
are more stringent than publishing an experimental document.

Mike

On Tue, Oct 30, 2012 at 3:29 PM, S Moonesamy <[email-masked]> wrote:
> Could the WG let me know whether the following is an adequate summary of the
> discussion about the proposal?  Please note that this message is not about
> debating about the views that were expressed.  There should be ample time
> during the face-to-face (Jabber for remote participants) meeting for that
> discussion.
>
> nothing to do with interoperability, security, or other topics critical to
> defining a protocol and enabling interoperability.  Much of that bloat may
> well have been there in RFC4408 itself, and the working group has focused on
> developing it rather than cleaning it up. [1]
>
> John Leslie mentioned that "we're going 'round in circles largely because we
> have differing opinions on what is protocol and what is operational advice."
> [2]  William Leibzon noted that that such re-organization is likely to go
> against original intent of SPF.  The intent was to have it published as a
> standard document and if part of it is split into "informational" type
> document that is very different especially given that SPF was published as
> experimental standard already [3].  Dave Crocker posted the following
> questions [4]:
>
>
>  1. Is it generally 'legal' to reorganize a specification document during an
> effort
> Scott Kitterman mentioned that the current document (4408) is the basis for
> multiple, interoperable implementations [5].  William Leibzon mentioned that
> the material has been used and understood by countless developers [6].
> Alessandro Vesely commented that Version -07 was still organized according
> to RFC 4408, with such idiosyncrasies as putting macros after Received-SPF
> rather than along with mechanisms and modifiers where they pertain and
> separating filter handling from the result computation is a needed cleanup
> that this reorganization opens nicely [7].  Arthur Thisell commented that
> Andrew Sullivan tried to clarify the goals of the discussion about the
> proposed reorganization [9].
>
> Regards,
> S. Moonesamy
>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 31 Oct 2012 12:43:11 +0100

> participants) meeting for that discussion.

Hm.. not sure what you mean by adequate.  The summary is rather
euphemistic :-)

> [...]  Dave Crocker posted the following questions [4]:
> 
>    during an effort like spfbis and specifically legal for spfbis?
> 
> 3. Does the proposed reorganization increase clarity or otherwise
>    improve the document?

Those are good questions, but IMHO we should first clarify what
exactly do we want to standardize.  Specifically, whether we want to
cover receiver behavior or not:

If we standardize just the *SPF function* then we should severely cut
the bloat.  For example, considerations about whether the function is
computed on a mail server rather than some other kind of host --which
used to constitute experimental guidance-- becomes 98% fluffy in a
standard document.  Not to mention SMTP reply codes.

If we want to standardize *SPF implementation*, since most concerned
software runs at SMTP servers, we have to specify it much better than
what is currently drafted, using MUSTard like e.g. RFC 6647 does.
That may imply splitting the document.

---

From: Hector Santos <[email-masked]>
Date: Wed, 31 Oct 2012 12:27:03 -0400

IMV, this is confusing and I don't believe it captures all the 
concerns here 100%.  There is some that appear to be misread and other 
statements not even included.

Nonetheless, there are some key issues IMO need to be resolved before 
any decision on reorganization, fine tuning or "reduction" of RFC4408 
can be properly done.  If we can't agree with some of the key and 
central issues, I doubt a reorganization will resolve the disagreement 
with satisfaction.  However, a higher concern is it could do exactly 
the same thing that hurt the DKIM protocol and its potential payoff value:

    - Relaxation of the strong security value of the SPF protocol,
    - Remodeled around an abstract REPUTATION framework

IMV, This has been among the central debate with SPF here which IMV, 
lead the WG to an impasse.  Some don't like the current specification 
description and any implied strong operation of a -ALL (Failed) and 
wish it to be watered down in the name of using integrated heuristics 
methods, especially methods offered by Reputation services 
(borderlines conflict of interest concerns among others already 
exhibited in the WG).

I think there is a lost of SPF "BIS" focus in this group because in 
large part, there has been concerted effort to alter the SPF 
specification so it can work with other protocols written by the same 
concerted group. That has a air of conflict of interest.

-- 
HLS

S Moonesamy wrote:
> Could the WG let me know whether the following is an adequate summary of 
> the discussion about the proposal?  Please note that this message is not 
> about debating about the views that were expressed.  There should be 
> ample time during the face-to-face (Jabber for remote participants) 
> meeting for that discussion.
> 
> nothing to do with interoperability, security, or other topics critical 
> to defining a protocol and enabling interoperability.  Much of that 
> bloat may well have been there in RFC4408 itself, and the working group 
> has focused on developing it rather than cleaning it up. [1]
> 
> intent was to have it published as a standard document and if part of it 
> is split into "informational" type document that is very different 
> especially given that SPF was published as experimental standard already 
> [3].  Dave Crocker posted the following questions [4]:
> 
> improve the
> Scott Kitterman mentioned that the current document (4408) is the basis 
> for multiple, interoperable implementations [5].  William Leibzon 
> mentioned that the material has been used and understood by countless 
> developers [6].  Alessandro Vesely commented that Version -07 was still 
> organized according to RFC 4408, with such idiosyncrasies as putting 
> macros after Received-SPF rather than along with mechanisms and 
> modifiers where they pertain and separating filter handling from the 
> result computation is a needed cleanup that this reorganization opens 
> nicely [7].  Arthur Thisell commented that deciding the order of the 
> macro and received-spf headers is not important [8].
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 31 Oct 2012 12:50:09 -0400

-- 
HLS