Subject: [spfbis] A proposed reorganization

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 12:12:04 -0700

I've taken some time to construct a proposed restructuring of the
current spfbis draft.  Since we're ruminating now about the idea of
splitting the document, it seems like we might benefit from having an
example to consider.

I have showed this already to Scott, who is of the opinion that it
doesn't bring enough benefit to be worth doing (I'm sure he'll provide
more detail about that on this thread).  On the other hand, I rather
like the proposed arrangement, for reasons described below.  The point
of posting this now is to get other opinions.

I recently conducted a high-level review of the -07 draft of spfbis,
as compared to a more detailed technical review I did earlier.  The
focus here was thus more on organization and presentation of the
material rather than getting the technical details right.

SPF is a protocol, and this is the document that defines it.  It 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.
 I've taken a stab here at doing the latter.

It's important to note that absolutely nothing has been removed from
-07 here, though while hacking on it I did reword a few things along
the way to improve the presentation.  This is simply a proposed
rearrangement of the material.  I also added one or two paragraphs
that have already had some discussion on the list to see if they fit,
and I think they do.  Of course, the whole thing has to have consensus
to carry forward.

I've tried to arrange it the way I believe protocols and algorithms
are generally described, like a man page or an RFC would be, in this
sort of order:

INTRODUCTION:
Section 1: Problem Statement/Introduction, Terminology
Section 2: Basic Inputs, Basic Outputs, Establish Context

DETAILS:
Section 3: Policy Statement Syntax
Section 4: Function Definition, i.e. How To Write check_host()
Section 5: Enumerate and Describe Mechanisms
Section 6: Enumerate and Describe Modifiers
Section 7: Macros

OPERATION:
Section 8: Details about Outputs, Pedagogy, Interpretation
Section 9: Recording Results in Headers
Section 10: Affects on Infrastructure
Section 11: Security Considerations

REQUIRED STUFF:
Section 12: Acknowledgements
Section 13: IANA Considerations
Section 14: References

EXTRA BITS:
Appendices

A number of sections in the -07 draft have been carved up and moved
into Appendices C through I because they appear to be detailed
operational advice or even vague suggestions rather than core protocol
material.  Those, I believe, are candidates for being moved out into
an Informational operations guide to reduce the size of the core
specification.  I believe some of what's now Sections 8 and 10 could
also go if we want to be more aggressive about this kind of cleanup
work.  Or if we want to be less aggressive, just leave them all as
appendices of the core document.

While talking to Pete about some charter topics in one of my other
working groups, I did broach the subject of the split of spfbis into a
proposed standard and an informational, and he appeared to agree that
it would only be a milestone change and not a full charter update that
would need IESG approval.  Thus, procedurally, this is a lightweight
move if we choose to make it.  The co-chairs just need to decide upon
editor(s) and away we go.

The diff is at http://www.blackops.org/~msk/spfbis/reorg.html.  I look
forward to your comments.

-MSK

---

From: John Leslie <[email-masked]>
Date: Fri, 14 Sep 2012 16:19:29 -0400

> Section 13: IANA Considerations

   It's hard to know what to make of this... My initial impression is
that we'd do better to consider what could be split off into an
Applicability Statement.

   For example, I would guess that Sections 9 and 10 deserve to be
split off, and I'm confused about Section 8. There would have to be
a Security Considerations as part of the protocol specification; but
there might also be Security Considerations that belong to an
Applicability Statement.

> editor(s) and away we go.

   For purposes of discussion, I strongly recommend that we consider
any possible need to "recharter" to do a split out-of-scope here. I'm
100% confident that Pete would take care of any such need if we show
him that the WG wants to split the document.

   IMHO, we're going 'round in circles largely because we have differing
opinions on what is protocol and what is operational advice.

--
John Leslie <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 13:22:53 -0700

> that we'd do better to consider what could be split off into an

Exactly, and one of the goals of this exercise is to "group" that text
in such a way that extracting it, or imagining what that would look
like, is much easier.

> there might also be Security Considerations that belong to an

I think parts of Section 8 probably also qualify.  That's for us to
discuss here as a group.  Have at it.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 13:27:04 -0700

> Section 10: Affects on Infrastructure

Effects.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 13:32:41 -0700

>> Section 10: Affects on Infrastructure

Stop that!

---

From: William Leibzon <[email-masked]>
Date: Fri, 14 Sep 2012 13:41:07 -0700

I've been lurking and not posting but here I'd like to note 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. In general I'm
actually under the impression that instead of doing real "SPFbis" and
polishing a doc (which we already did quite a bit of work on before) for
proposed standard you're in fact starting back on MARID-like discussions
that chair himself regarded as inappropriate. This also very reminds me of
when original SPF was sent to publication and then area director tried to
change important SHOULD to some non-capitalized word right before it was to
be published hoping we'd not notice. This appears to be somewhat similar on
larger scale. Please keep in mind original intent of the document to
provide a standard way to protect your from abuse of MAIL FROM by spammers
and fraudsters.

On Fri, Sep 14, 2012 at 12:12 PM, Murray S. Kucherawy
<[email-masked]>wrote:

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 13:59:05 -0700

On Fri, Sep 14, 2012 at 1:41 PM, William Leibzon <[email-masked]> wrote:
> that SPF was published as experimental standard already.

What's an "experimental standard"?

In IETF terms, it's either Experimental or Proposed Standard.  SPF is
the former.

> In general I'm
> that chair himself regarded as inappropriate.

That's manifestly not what I'm proposing here.  As I said, there's
complete preservation of the material with a couple of minor things
that I believe the WG was already trying on for size.  I'm proposing
what I believe is an improvement in the presentation of the very same
material.  How could that be construed as a re-hashing of off-topic
discussions?

> This also very reminds me of
> larger scale. Please keep in mind original intent of the document to provide
> a standard way to protect your from abuse of MAIL FROM by spammers and
> fraudsters.

I don't think any of the intent or the technical details have been
obscured.  The material has just been reorganized.

Let me put the challenge back to you: Why should we presume that the
organization and presentation of RFC4408 is optimal?  Will the IESG,
now reviewing this as a Proposed Standard instead of the lower bar of
Experimental, agree that the older document got it completely right?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 17:01:44 -0400

>opinions on what is protocol and what is operational advice.

I see a split between people significant implementation/operational experience with SPF and standards professionals.

My primary audience is not the IESG.  It's the people who have to implement and deploy SPF based on 4408bis.  If we can make a better document for them, some additional work to explain and evangelize doesn't bother me a bit.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 14:59:40 -0700

On 9/14/2012 12:12 PM, Murray S. Kucherawy wrote:
> current spfbis draft.
...
> however become somewhat bloated with documentation of nuance and other
...
> -07 here,
...
> move if we choose to make it.

I've attached a side-by-side of the existing and proposed tables of 
contents, so that it is possible to compare the two directly.

Here's the way it looks to me:

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

    My experience is that these sorts of efforts always permit 
reorganization of the specification document.  And Murray's gotten 
specific agreement from our AD that it's legal.

    My experience also has been that part of gaining experience with a 
specification is learning how to make the document more helpful to new 
readers.  And I think that's the interesting target audience for a spec. 
  Not the current workers and not IETF management, but rather folk who 
are outside the SPF culture but who want to implement it.

2. Does the existing organization have some issues?

    A specification that has its first substantial section be 
"Operations" almost certainly can benefit from a better logical 
sequence.  Operations needs to come after technical foundation and after 
protocol specification.  Operation is about /use/.

    As another example, the current version has Macros coming after 
Recording the Result.  Yet macros are part of the protocol engine, 
whereas Recording the Result refers to some that is done /after/ the 
protocol engine is completed.

    In other words, I think there is a pretty strong case to be made for 
trying to improve the document's organization.

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

    Murray's proposal looks pretty reasonable to me.

    It's always possible to debate some details.  For example, I'm 
wondering whether his Section 7, Macros, shouldn't come two or three 
places earlier in the sequence, such as right after his 3 or 4.  But 
that's a question, not a suggestion.

    Or maybe I'm wondering why check_host() doesn't come after Macros?

    But these are very narrow points. Overall the proposal looks like an 
improvement to me.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 15:07:05 -0700

On Fri, Sep 14, 2012 at 2:59 PM, Dave Crocker <[email-masked]> wrote:
> Not the current workers and not IETF management, but rather folk who are
> outside the SPF culture but who want to implement it.

To clarify that point: I'm not trying to make it readable for the
IESG.  I'm pretty sure they'll get the material.  Rather, the IESG is
going to ask themselves this same question: Is the format of this
document optimal for new readers?  So I believe they and I have the
same audience in mind.  And given that, I think the layout of -07 can
be improved, hence this work.

>    Or maybe I'm wondering why check_host() doesn't come after Macros?

I considered that as well, inasmuch as check_host() implements macros,
so defining them first makes sense.  A valid suggestion.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 18:56:06 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:

>are

The current document (4408) is the basis for multiple, interoperable 
implementations.  Most of them done by people with little or no interaction 
with the SPF community.  I once did a small consulting project for a large 
vendor to help them figure out how to implement SPF (I reviewed their design) 
and it turned out that virtually everything that was unclear to them was how 
Sender ID and SPF relate.  SPF itself they were able to develop a design to 
implement just fine using RFC 4408.

http://james.apache.org/jspf/ is a free software example.  They had a few 
questions that they asked, but fundamentally, they implemented it on their own 
based on the specification and the associated test suite.

Given the success of the current document, I think it deserves a certain 
degree of presumption of correctness.  We have data to support it being 
effective.  For any alternative arrangement or splitting it is a matter of 
speculation if it would better or not.

Even if you think a new arrangement is better, I don't think that's enough.  
While new implementers are certainly A target audience, they are certainly not 
the only one.  People updating existing implementations are also a target 
audience.  I believe this will be much larger, but even if it's not, it will 
certainly exist.  

The more difficult we make it to understand what's changed between 4408 and 
4408bis, the more difficult it will be for this class of users to correctly 
update to match what's in 4408bis.  Any reorganization has a presumptive 
negative value that it needs to overcome.

Finally, splitting into two documents makes things much harder to use.  Not 
only does it require the reader to jump between documents, it substantially 
constrains our ability to make specific references between text (I'd be glad to 
be proven wrong on this if someone knows how).  Currently in 4408bis there are 
links between various areas in the core protocol piece of SPF and the 
supporting information (section 9) that are to targets within the section.  An 
HTML representation of 4408bis will have hyperlinks to the specific location.  
If some or all of what's in section 9 were in a separate document, such links 
could only be made to the document and not to specific targets within the 
document.  This will make it more difficult, particularly for new people to 
navigate their way through the specs.  IF my understanding is correct, I think 
it's a good reason NOT to split and sufficient on it's own, so there's no point 
in a document reorg that makes splitting easier.

In the mean time, we're going to lose more time spinning our wheels on a 
decision that doesn't have a lot of potential to add significant value.  In the 
mean time, so that Murray's diff will apply if there is rough consensus for his 
organization, I'm going to hold off on making local changes.  I'd hate for him 
(or me) to have to redo the work.  Even though I'm not supporting the result, 
I appreciate the effort he went to.

Scott K

---

From: William Leibzon <[email-masked]>
Date: Fri, 14 Sep 2012 16:40:51 -0700

> In IETF terms, it's either Experimental or Proposed Standard.  SPF is

I know what IETF terms are. But the use of SPF has been equivalent to
proposed standard despite its official experimental status which was you
know a political decision when disbanding MARID. That is why I think this
group should treat changes from RFC4408 as somewhat similar to proposed to
draft. And originally when I heard, I thought you would just bring SPF into
official status and get errata in instead of doing so many changes and
additions.

> material.  How could that be construed as a re-hashing of off-topic

I've heard of others calling to split it into multiple docs. I'm totally
against this. But I'd like to cut down on so much language in current doc
though.

> provide

Not picking specifically on this proposal, but I've had a problem with some
of the things I could see from discussions (though I've only had enough
time for quick-reading from July).

You should not be downgrading language related to SPF FAIL results because
fail is exactly what the original intent of SPF as a way to stop spoofing
for those who want it. Its also exactly why there is a softer ~ which I
happen to use myself more often.

And though I'm not at all a fan of ptr macros either, they are part of
original specification and implementations and removing them is only if
there are security considerations (which I happen to think there are so
here I agree).

> Experimental, agree that the older document got it completely right?

The material has been used and understood by countless developers. Unless
there is a strong reason to believe the material is not clear and structure
is bad, and such complaints come from developers rather than from folks
here, the current structure should be considered good.

William

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 16:57:51 -0700

On 9/14/2012 4:40 PM, William Leibzon wrote:
> know a political decision when disbanding MARID. That is why I think
> this group should treat changes from RFC4408 as somewhat similar to
> proposed to draft. And originally when I heard, I thought you would just
> bring SPF into official status and get errata in instead of doing so
> many changes and additions.

1. We aren't doing "so many changes and additions".

2. It's a bit dangerous to impose additional rules on an IETF working 
group, based on your own assessment, given that there is already quite a 
bit of constraint on the process.

3. Your assessment -- or rather, the truth of it -- doesn't matter for 
the question at hand.  For example, we made significant changes to the 
DKIM doc when moving from Proposed.  The rationale for some of the 
changes was the same as here: documentation clarity.

> The material has been used and understood by countless developers.
> Unless there is a strong reason to believe the material is not clear and
> structure is bad, and such complaints come from developers rather than
> from folks here, the current structure should be considered good.
> William

I suspect you haven't done a survey of all the actual or potential 
readers of the documents.  We can't know who has had troubles with the 
document.

Rather than resorting to "lots of people were able to use it in its 
current form", it would be useful to focus on the issues that have been 
cited and the improvements in Murray's proposal.

d/

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2012 00:00:18 -0000

I'm with Dave, the reorg is easier to follow.  I have some niggles,
e.g. the section on "fail" result still has some local policy stuff
that needs to either move to the end or disappear, but it's definitely
an improvement.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 22:20:37 -0400

>changes was the same as here: documentation clarity.

It was called that for process convenience, but at least some of this so 
called clarifications were substantiation semantic changes that changed DKIM.  
I am trying very hard to avoid a similar success with SPF.

>cited and the improvements in Murray's proposal.
Having invested significant personal time over the course of seven years 
answering questions for both implementors and domain owners trying to deploy 
SPF, in addition to working on both SPF library implementations and 
code/process into integrate SPF into a variety of mail systems, I think I have 
at least as much experience as anyone on the list trying to help people 
through problems with RFC 4408 and more than most.

Record publishers with questions typically have a hard time conceptualizing 
that the SPF record is intended to describe the outbound mail architecture of 
their domain(s).  This is as foreign a concept to many of them as controlling 
open relays was in the 1990's.

Many domain owners are very non-technical and they end up needing to have 
basic DNS concepts explained to them.

I don't recall, except for making processing limits clearer (which we are 
doing) thinking the spec needed improvement from a publisher's perspective.

I'm thinking back and I don't recall any issues for implementers that aren't 
documented in errata.  That's the primary source for them.  You'll also notice 
that it's been some years since new erratum were filed.

Of course no one has done a survey of all actual or potential readers.  It's a 
nonsense point.  I don't know why you mention it.  The fact is that the 
existing text and structure has demonstrated considerable success.  Any 
alternative, by definition, has not.

I had a chance to review Murray's proposal before it was published.  It is 
different than the organization in RFC 4408.  I don't find it better in any 
significant respect.  Moving things like experimental history and such to the 
end make sense, but in terms of the reorganization of sections 2 through 9 
into more sections and an additional stack of new appendices, I don't find it 
an improvement.  It spreads things out over several sections so there is much 
more need to hop around the document when focusing on a single concept.  I 
don't think it's an unreasonable way to go about things, I just don't think 
it's overall an improvement.

The only issue I see is some people don't like the way RFC 4408 was structured 
and some others are convinced the IESG won't like it.  Balanced against a 
demonstrated record of success, I think opinions of people who've never 
actually implemented or operated this (or particularly helped a broad base of 
others to do so) should not merit a lot of weight.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 22:22:15 -0400

> that needs to either move to the end or disappear, but it's definitely

Let's focus on one thing at at time.  I understand you want to morph SPF into 
something other than what it was in RFC 4408, but let's focus on Murray's 
arrangement and not your issues with the content.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2012 03:34:15 -0000

>arrangement and not your issues with the content.

Like I said, the arrangement is an improvement, but there's still more
that needs reorganizing.

The item I mentioned is in the description of "fail" status, where
there's a lengthy discussion of how to do an SMTP code 550 reject.
That's local policy, so it belongs in the back, not in the normative
part.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 23:41:22 -0400

On Saturday, September 15, 2012 03:34:15 AM John Levine wrote:
> >Let's focus on one thing at at time.  I understand you want to morph SPF
> >into something other than what it was in RFC 4408, but let's focus on
> >Murray's arrangement and not your issues with the content.
> 

If you want to redefine what SPF is, that's true.  I don't think we're 
chartered to do that.  Despite what several people are saying SPF has always 
been more than address/hostname/IP in and result code out.  Others have 
equally overstated what it was.  RFC 4408 carefully takes no position on what 
action local policy should prefer.

I think we're much better off to leave things like this alone and focus on 
finishing fixing actual errors and issues.  The reorg is going to suck up a week 
or two and then I suspect that we'll argue about whether to narrow what SPF is 
or not until the chairs tell us to stop.  Once both of those are done, maybe 
some actual work will get done.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Sep 2012 21:24:38 -0700

> official status and get errata in instead of doing so many changes and

I don't know of any restrictions on upgrades from Proposed to Draft
that forbid reorganization of the material if there's consensus around
a better presentation.

> against this. But I'd like to cut down on so much language in current doc

Some of this work could also be used if that's the goal.

> happen to use myself more often.

In my view, we've settled on the notion that SPF shouldn't be
dictating what "fail" means to any given receiver.  If that means
downgrading the language from RFC4408, then that's the right thing to
do.

> here, the current structure should be considered good.

That nobody has complained doesn't mean it can't be improved.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Sep 2012 11:54:35 +0200

> forward to your comments.

I think Murray's work is an important step in the right direction.

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.

Separating filter handling from the result computation is a needed
cleanup that this reorganization opens nicely.  Since the early SPF
drafts, which provided the actual basis for development, the passages
about local policy have been progressively blurred and enlarged until
RFC 4408.  The result is only comprehensible by the developers who
followed the whole history, and transmitted by word of mouth ever
since --one of the recurring "mantra" was recently mentioned on this
list.  A Proposed Standard is not an esoteric cult scripture, though.

+1 for adopting this change.

---

From: Hector Santos <[email-masked]>
Date: Sat, 15 Sep 2012 04:16:53 -0400

Murray S. Kucherawy wrote:

>> William Liebzon:

+1

> dictating what "fail" means to any given receiver.  

-1. Who is we? Was there a consensus call?

> If that means downgrading the language from RFC4408, then that's 
> the right thing to do.

-1. It is not the right thing to do.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Sep 2012 12:41:50 +0200

Hector and all, particularly those of us who Scott identifies as
having "significant implementation/operational experience with SPF"
(as opposed to "standards professionals".)

On Sat 15/Sep/2012 10:16:53 +0200 Hector Santos wrote:
>> On Fri, Sep 14, 2012 at 4:40 PM, William Leibzon wrote:
>>
>>> You should not be downgrading language related to SPF FAIL
>>> results because fail is exactly what the original intent of SPF
>>> as a way to stop spoofing for those who want it. Its also
>>> exactly why there is a softer ~ which I happen to use myself
>>> more often.
> 
> +1

Do we realize that, in order to downgrade something, that has to be
resting at a status higher than zero?  I've been told for years that
SPF has no shadow of a mandated receiver behavior whatsoever, because
it is a sender and not a receiver policy.

OTOH, standards professionals say that specifying message disposition
based on SPF results might be quite reasonable.  That means it is
possible to formulate the specification such that each part spells its
topic straight, clear, and with the adequate amount of MUSTard.

Who is preventing SPF from expressing its original intent, then?

> -1. Who is we? Was there a consensus call?

That's not a new opinion, it's a fact.  You know better than I that
neither RFC 4408 nor bis-07 dictate anything to receivers.  One has to
read between the lines in order to grasp that meaning.  You had to
resort to a 2004 draft to find a "MAY reject".

It is also a fact in terms of deployment.  Since the +1 above was not
meant for publishing ~, you know that -all is almost never honored.

> -1. It is not the right thing to do.

Murray didn't downgrade, but insulate that text.  A necessary step if
we aim at making it sharp.  Clearness matters more than page number.

By denying consensus, neither Murray's step nor the split will occur.
 That's the wide and easy road to have our job done quickly, but it's
a lost opportunity for SPF, and probably not the reason why you joined
this WG.  Please breath and, please, consider carefully.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 16 Sep 2012 09:18:41 -0400

>meant for publishing ~, you know that -all is almost never honored.

Not quite.  4408/4408bis avoid specifying what receivers should DO with SPF fail.  That's very different than not defining what SPF fail means.  I agree that the current draft is equivalent to 4408 on the topic of what to do about SPF fail, after all, I wrote it.

What I object to is the current jihad against anything that even vaguely looks like it might be receiver policy that will make the specification different than RFC 4408 and different than what we were chartered to produce.

That set of objections is somewhat independent of my dislike of the reorg, although the reorg is related because it's a first step to removing things that I think should not be removed.

Even if it weren't though, I still don't think it improves the document and we shouldn't do it.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2012 17:51:43 -0000

>Not quite.  4408/4408bis avoid specifying what receivers should DO with SPF fail.  That's
>very different than not defining what SPF fail means.  I agree that the current draft is
>equivalent to 4408 on the topic of what to do about SPF fail, after all, I wrote it.

Well, except that 2/3 of the text in the fail section is a description
of how to do an SMTP time reject.  I don't think it's totally off the
wall to worry that people would misinterpret that to mean that it's
the recommended receiver behavior, or what everyone does, rather than
a fairly unusual receiver policy used only by a handful of small mail
systems.

Like I keep saying, if the example belongs anywhere, it belongs back
with the other examples, not in the middle of the normative text.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 16 Sep 2012 11:22:38 -0700

> What I object to is the current jihad against anything that even vaguely looks like it might be receiver policy that will make the specification different than RFC 4408 and different than what we w…

Hyperbole aside, I don't believe any of the proposed changes fail to
meet the charter.  We are expressly chartered to fix errors and
clarify things that need clarification.  If there are participants who
feel that the available text is in need of such, and are offering
contributions to that end, then stomping all over those contributions
and waving the charter at them isn't appropriate.  Disagreement is
fine, of course -- I fully realize that it's on me to garner consensus
for a change like this --  but all of this aggressive dismissal is
going just a bit too far.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 16 Sep 2012 14:50:25 -0400

>with the other examples, not in the middle of the normative text.
I think the question of where best to put examples is both reasonable and well in scope. It does sound to me like you're worried people will believe the spec means things it doesn't say.  We can't stop that.  I think you worry too much.  Approximately all the people I'm aware of that have been confused by this are active on this list, so I think it may bias your perspective of the risk.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 16 Sep 2012 15:07:20 -0400

Scott Kitterman wrote:

>> Levine:
> I think the question of where best to put examples is both reasonable 
> and well in scope. 

For the record, there are already examples in section 7.1, in fact, 
only for a PASS and FAIL for a Received-SPF where the latter would 
only fit a accept+mark optional protocol behavior:

    Received-SPF: pass (mybox.example.org: domain of
     [email-masked] designates 192.0.2.1 as permitted sender)
        receiver=mybox.example.org; client-ip=192.0.2.1;
        envelope-from="[email-masked]"; helo=foo.example.com;

    Received-SPF: fail (mybox.example.org: domain of
                      [email-masked] does not designate
                      192.0.2.1 as permitted sender)
                      identity=mailfrom; client-ip=192.0.2.1;
                      envelope-from="[email-masked]";

I was going to post an issue regarding providing additional realistic 
examples for each possible Received-SPF result (like pre-4408 had). 
It should be noted for the fail Received-SPF trace may not, in fact, 
exist when a rejection optional protocol behavior is active.

Suggestion:

For starter text, look at the pre-4408 draft where it has an example 
for each possible result and use something similar for 4408BIS.  In 
fact, I recall using the comments in the trace as default text for our 
SPF API "check_host()".  Finally,  Add the note regarding the specific 
fail trace may not exist for SPF receivers deploying rejection at SMTP 
level before the DATA (Mail is not accepted and marked).

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 16 Sep 2012 15:00:14 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:

>> What I object to is the current jihad against anything that even
>vaguely looks like it might be receiver policy that will make the
>specification different than RFC 4408 and different than what we were
>chartered to produce.
>

The message you replied to wasn't about the reorganization.  I'm not in favor of the reorganization for reasons I've specified, but I agree it's within the scope of our charter.

It gets conflated with the local policy discussion for a variety of reasons.  Sorry for not being clearer.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 16 Sep 2012 15:43:49 -0400

BTW Scott, do you think the two Received-SPF examples of using a 
private IP subnet address (192) may be poor examples of a realistic 
SPF client/server transaction?

In other words, this leads itself to the forwarding problem where the 
internal network (private side relay) erroneously continues to perform 
a check_host() and thus a guarantee to create a multi-hop changed 
DOMAIN::IP assertion failure.

The examples should illustrate public IP address examples.  Unless of 
course, the "Received-SPF: fail" trace example itself was to suppose 
to illustrate the forwarding problem that is should be avoided by the 
internal ADMD (no additional SPF checks internally).

--
HLS

Hector Santos wrote:
> For the record, there are already examples in section 7.1, in fact, only 
> for a PASS and FAIL for a Received-SPF where the latter would only fit a 
> accept+mark optional protocol behavior:
> 
> examples for each possible Received-SPF result (like pre-4408 had). It 
> should be noted for the fail Received-SPF trace may not, in fact, exist 
> when a rejection optional protocol behavior is active.
> 
> Suggestion:
> 
> For starter text, look at the pre-4408 draft where it has an example for 
> each possible result and use something similar for 4408BIS.  In fact, I 
> recall using the comments in the trace as default text for our SPF API 
> "check_host()".  Finally,  Add the note regarding the specific fail 
> trace may not exist for SPF receivers deploying rejection at SMTP level 
> before the DATA (Mail is not accepted and marked).
> 
> -- 
> HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 16 Sep 2012 16:22:06 -0400

Hector Santos <[email-masked]> wrote:

>only 
>It 
>for 

Those are the designated example IP addresses, not private addresses.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Sep 2012 11:36:55 +0200

On Sun 16/Sep/2012 15:18:41 +0200 Scott Kitterman wrote:
> 
> 4408/4408bis avoid specifying what receivers should DO with SPF
> fail.  That's very different than not defining what SPF fail
> means.

Hm... it means the receiver should do something with it, no?  A quite
elusive stance, really.

> specification different than RFC 4408 and different than what we
> were chartered to produce.

s/even/only/ and I'm with it.  We should either specify something
clearly or not mention it at all, no matter how important it is.

Now that brings up an interesting question on charter interpretation,
where it limits changes to the SPF specification:  I'm unable to
contradict Hector when he says SPF always implied a domain intent and
expectation for using a hard -ALL failure policy.  Indeed, based on
the I-D, we'd be charged for abetting behavior, if that were a crime,
and convicted.  I mean, SPF does specify receiver behavior, albeit
between the lines.  So, when the charter talks about clarifying the
spec, what does it mean?  We can pretend that SPF says nothing about
it, and do that jihad.  Or we can translate SPF's true meaning into
clear text, for example as touched upon in the last sentence of
http://www.ietf.org/mail-archive/web/spfbis/current/msg02870.html

AFAICS, other approaches will result in a specification prone to
misinterpretation, which I'd avoid if at all possible.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Sep 2012 09:46:08 -0700

Scott,

On 9/14/2012 7:20 PM, Scott Kitterman wrote:
>>> I know what IETF terms are. But the use of SPF has been
>>> equivalent to proposed standard despite its official
>>> experimental status which was you know a political decision when
>>> disbanding MARID. That is why I think this group should treat
>>> changes from RFC4408 as somewhat similar to proposed to draft.
>>> And originally when I heard, I thought you would just bring SPF
>>> into official status and get errata in instead of doing so many
>>> changes and additions.
>>
>> 2. It's a bit dangerous to impose additional rules on an IETF
>> working group, based on your own assessment, given that there is
>> already quite a bit of constraint on the process.
>>
>> 3. Your assessment -- or rather, the truth of it -- doesn't matter
>> for the question at hand.  For example, we made significant
>> changes to the DKIM doc when moving from Proposed.  The rationale
>> for some of the changes was the same as here: documentation
>> clarity.
>>
>
> It was called that for process convenience, but at least some of
> this so called clarifications were substantiation semantic changes
> that changed DKIM. I am trying very hard to avoid a similar success
> with SPF.

1. I cannot quite figure out what your use of "It" refers to.  My guess 
is that it refers to the document status, but would appreciate your 
clarifying or at least confirming.

2. My point was that the 'Experimental' vs. 'Proposed' status difference 
does not matter with respect to the document reorganization being 
proposed.  There is (typically) no restriction against such changes and 
certainly isn't one that I see in the SPFbis wg charter.

3. You appear to believe that changing document organization somehow 
changes SPF syntax or semantics.  Please explain that view.

4. You assert that there are "substantial semantic changes that changed 
DKIM".  First, DKIMbis had a significantly different charter, and second 
if you are going to invoke DKIM work as somehow relevant to SPFbis work, 
please provide direct explanation of the relevance. Presumably you are 
making a claim of substantial changes to DKIM semantics as a sort of 
justification for not making some sort of change to the SPF 
specification, but I can't tell how to apply it, since there are no 
specifics offered.

>>> The material has been used and understood by countless
>>> developers. Unless there is a strong reason to believe the
>>> material is not clear
>> and
>>> structure is bad, and such complaints come from developers
>>> rather
>> than
>>  readers of the documents.  We can't know who has had troubles
>> with the document.
>>
>> current form", it would be useful to focus on the issues that have
>> been cited and the improvements in Murray's proposal.
>>
> Having invested significant personal time over the course of seven
> years answering questions for both implementors and domain owners
> trying to deploy SPF, in addition to working on both SPF library
> implementations and code/process into integrate SPF into a variety
> of mail systems, I think I have at least as much experience as anyone
> on the list trying to help people through problems with RFC 4408 and
> more than most.

This is called an appeal to authority:

    http://en.wikipedia.org/wiki/Argument_from_authority

It has its uses, but typically is problematic.  It often is used in 
place of providing meaningful justification for a view.  And indeed I 
can't tell how you mean it to be applied here.

In the extreme, it might be your assertion that because you have not 
seen certain issues over the course of your extended experience, they 
are not real or significant issues.  Taken to its logical conclusion, 
that probably would mean ignoring all errata, except the ones that you 
have encountered.

> Record publishers with questions typically have a hard time
> conceptualizing that the SPF record is intended to describe the
> outbound mail architecture of their domain(s).  This is as foreign a
> concept to many of them as controlling open relays was in the
> 1990's.

"outbound mail architecture" is an interesting phrase.  I think I 
haven't heard it before, but it sounds potentially useful.

The only caution I'd raise is the difference between protocol 
architecture, software architecture and operations (or deployment) 
architecture.  In practical terms, people often get confused about the 
word 'architecture'.  To avoid that confusion in this case, I might 
suggest saying 'outbound mail configuration', but that doesn't sound a sexy.

> Many domain owners are very non-technical and they end up needing to
> have basic DNS concepts explained to them.

Of course, your comment is correct, but I am not understanding its 
relevance to the current discussion.

One use that is probably not what you intended is that readers of RFCs 
also often do not understand some basic issues.  Indeed, one of the 
things I like about IETF specification style is that we have a freedom 
to include tutorial material and, more general, to attend to the 
pedagogic aspects of specifications more than most other standards groups.

This happens to be why I'm in favor of the proposed re-organization:  It 
is cleaner and follows a better logical sequence.  That makes is more 
helpful to a broader base of readers.

> I don't recall, except for making processing limits clearer (which
> we are doing) thinking the spec needed improvement from a
> publisher's perspective.
>
> I'm thinking back and I don't recall any issues for implementers
> that aren't documented in errata.  That's the primary source for
> them. You'll also notice that it's been some years since new erratum
> were filed.
>
> Of course no one has done a survey of all actual or potential
> readers.  It's a nonsense point.  I don't know why you mention it.

It was my way of suggesting that your apparently relying only on your 
personal experience is a form of statistics sampling error.

When making claims about a population -- such as the entire set of 
existing and potential readers of SPFbis -- it is almost never 
sufficient to cite only one's own experience, no matter how extensive. 
It's relevant, but not sufficient.

> The fact is that the existing text and structure has demonstrated
> considerable success.  Any alternative, by definition, has not.

The original DKIM spec also demonstrated quite a bit of success.  So 
when we began its -bis effort, it was interesting to discover massive 
specification errors in parts of its formal details.

Success of a document version is important, but, again, not definitive.

> I had a chance to review Murray's proposal before it was published.
> It is different than the organization in RFC 4408.  I don't find it
> better in any significant respect.  Moving things like experimental
> history and such to the end make sense, but in terms of the
> reorganization of sections 2 through 9 into more sections and an
> additional stack of new appendices, I don't find it an improvement.

> It spreads things out over several sections so there is much more
> need to hop around the document when focusing on a single concept. I
> don't think it's an unreasonable way to go about things, I just don't
> think it's overall an improvement.

Please explain the claim that it requires more hopping around to use.

My own reading is that it provides more tightly coherent sequences -- 
although I and others have noted possible ways to improve the proposed 
organization further --  which is exactly the opposite interpretation 
from yours.

> The only issue I see is some people don't like the way RFC 4408 was
> structured and some others are convinced the IESG won't like it.

I think you've made the IESG reference a few times.  While there are 
some cases of possibly needing to pay attention to likely IESG issues, 
this hasn't been one of them, as I recall.  So I don't know why you are 
citing it.

> Balanced against a demonstrated record of success, I think opinions
> of people who've never actually implemented or operated this (or
> particularly helped a broad base of others to do so) should not
> merit a lot of weight.

Perhaps we can focus on the substance of suggested changes, rather than 
purported attributes of the speakers?

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Sep 2012 13:37:06 -0700

On Mon, Sep 17, 2012 at 9:46 AM, Dave Crocker <[email-masked]> wrote:
> I think you've made the IESG reference a few times.  While there are some
> cases of possibly needing to pay attention to likely IESG issues, this
> hasn't been one of them, as I recall.  So I don't know why you are citing
> it.

I'm the one who first raised that concern.  In my experience with
getting documents through IESG review, the flow of a document,
especially a proposed standard, is actually a common thing upon which
they push back or request improvement.  Considering that sooner rather
than during IESG evaluation seems a worthwhile optimization to me.

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.

>> particularly helped a broad base of others to do so) should not

I would think people who have actually implemented this in the past
are going to have the least amount of difficulty with whatever this
group produces, and thus people who are new to it are in fact the very
people about whom we should be most concerned.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 17 Sep 2012 16:54:12 -0400

> clarifying or at least confirming.

It is the process whereby DKIM was advanced in maturity status and 
simultaneously redefined.  It doesn't really matter though.  What was done with 
DKIM is, correctly, not directly relevant here.

> changes SPF syntax or semantics.  Please explain that view.

No.  I think the reorganization makes it harder to understand things.  It's 
the contemporaneous effort to expunge all mention of receiver policy that I 
believe changes things.

> specification, but I can't tell how to apply it, since there are no

Go read the original and current definitions for i=.  That will get you 
started, but we can drop it here.  It's not particularly relevant.

> can't tell how you mean it to be applied here.

First, while it's generally problematic, the page you says states that is is 
usually problematic because "either the Authority is not a subject-matter 
expert, or there is no consensus among experts in the subject matter".

I suggest that I am a subject matter expert (on SPF) and that among such 
subject matter experts this is general consensus on the points I'm making, so 
you objection generally good, is specifically not appropriate in this case.  
It's also an appeal to authority itself.

> that probably would mean ignoring all errata, except the ones that you

My assertion is that it's evidence that there are not real or significant 
issues.  I don't claim it's dispositive on it's own, but I think operational 
experience and evidence should be weighed heavily.  I think more than opinions 
of people who've just read the spec.

> haven't heard it before, but it sounds potentially useful.

It's one I've used for a long time.

> relevance to the current discussion.

If we're reorganizing the document to deal with problems, I think it's useful 
to point out the problems I have seen.  Hopefully an improved document would 
help address though.

> helpful to a broader base of readers.

I disagree.  It makes splits information about related topics up and makes it 
harder to find.  For example, if you're interested in getting feedback on your 
SPF deployment, 4408bis (both organizations) suggests two methods.  In -07 
they are together.  In the reorg, they are not.  I think this is the opposite 
of clarity.

> It's relevant, but not sufficient.

Of course not.  I'm interested in other people's experiences as well.  I'm 
much less interested in comments grounded in lack of experience.  They aren't 
all of equal value.

> Please explain the claim that it requires more hopping around to use.

I gave one example above.

> organization further --  which is exactly the opposite interpretation

Section 2.5 would be split in two and some information further split into 
appendicies.  You may find each individual bit more coherent, but I think that 
as a whole it's more scattershot.

snipped the IESG reference, since I replied to that already.

> purported attributes of the speakers?

If one person says a spec is usable and they've actually implemented stuff from 
the spec and one person say it is not, but they haven't, I don't think those 
opinions are inherently equal.  

I believe the guidance from the chairs has made discussion of most of my 
concerns OBE.  

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Sep 2012 18:00:40 -0400

Dear colleagues,

> I've taken some time to construct a proposed restructuring of the

Murray's suggestion has sparked a lot of conversation, some of it
quite heated (there have been some irrelevant and in some cases
personalizing remarks, too; we're dealing with those off-list). 

It seems to me there are several different issues here, and I'm not
entirely convinced we are attending to the central problems.  Indeed,
I'm having a hard time following some of the arguments (though SM is
less muddle-headed than I, and seems to me to have a better grasp of
matters).  So I'd like to sort out a couple of basic goals first, and
then see whether that gives us a clear direction.

The proposed reorganization depends on three basic premises: first,
that the current 4408-bis draft has grown and is a little unwieldy.
Second, it's not obvious that RFC 4408 was organized as well as it
could have been, nor even that it limited itself appropriately for
something that is on the standards track.  Third (and related to the
second), this document is moving to the standards track, and therefore
material that isn't really appropriate to a standards track document
should either be removed (possibly being moved into another document
-- leave aside the disposition for the moment) or moved into an
appendix or other clearly-marked, non-normative section.  These
premises seem to me to be at least plausible, if perhaps not
uncontroversially true.

The counter-argument to the proposed reorganization also,
conveniently, depends on three basic premises.  First, the WG is in
effect chartered to move SPF from the experimental to the standards
track, making as few changes to the protocol as technically possible
along the way.  Second, with large changes to the text, it is easy to
make accidental protocol changes that will go overlooked; it is also
possible for someone intending a change to the protocol to "sneak one
in" this way.  Third, by cleaving to the organization in RFC 4408, we
make it possible to compare the two documents easily, which defends
against the accidental (or intentional) changes going unnoticed.
These premises also seem to me to be plausible, if perhaps not
uncontroversially true.

Before going further, I'd like for participants in this debate to state
where they stand with respect to the above arguments, and to clarify
what trade-offs they think are acceptable as a result.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Sep 2012 15:58:02 -0700

Scott,

On 9/17/2012 1:54 PM, Scott Kitterman wrote:
> simultaneously redefined.  It doesn't really matter though.

The fact that you continue to make such an assertion -- and to make it 
in this forum -- remains problematic.

I assume that the specific is as you cited farther down, about i=. 
Unfortunately, for its supposed relevance to the current -bis effort, 
fixing that specification error was in response to an errata, AND it was 
/before/ DKIMbis was started.  It also didn't really change DKIM, except 
for resolving a fundamental ambiguity in output semantics.

> the contemporaneous effort to expunge all mention of receiver policy that I

The proposal concerns reorganizing the text.  A proposal to alter 
receiver policy language is -- or should be, IMO -- a separate topic.

As for being harder to understand, there have been specific observations 
about lack of logical sequence to the existing organization and even to 
possible layering violations in the way things are documented.  The 
latter was noted as inviting reader confusion, such as about 'fail' and 
an implied requirement for doing a specific SMTP failure code.

> started, but we can drop it here.  It's not particularly relevant.

Indeed, fundamental bugs the defininition of DKIM output, and common, 
disparate interpretations of i= and d= semantics were fixed.  But again, 
that was before the DKIMbis effort...

> expert, or there is no consensus among experts in the subject matter".

We can go with the latter, for the current purposes.

But you might also want to review the later section in the article, 
about Bias and prejudice.

> subject matter experts this is general consensus on the points I'm making,

I'll assume that you are not dismissing other 'subject matter experts' 
present in this forum, or rejecting their expertise?  And even if you 
are, you are now offering yourself as the expert about experts.  That 
repeats the problem of appeal to authority.

>    so

Wow.  That last sentence confuses the heck out of me.  In what way does 
it qualify as an appeal to authority?

> of people who've just read the spec.

For a topic like document reorganization, a relevant area of expertise 
is technical editing.  Specific examples have been provided about 
aspects of the current draft that suffer in the terms of good technical 
writing and especially good specification writing.

I thought that Murray's comments on this also quite useful.

> they are together.  In the reorg, they are not.  I think this is the opposite

Examples of the current document organization's conflating topics have 
been provided.  Feedback on the proposed change suggested refinements to 
it.  Certainly the kind of issue you cite would be something I'd expect 
a new and improved document organization to attend to carefully.

> much less interested in comments grounded in lack of experience.  They aren't

Forgive me, but I haven't noticed any process for assessing empirical 
knowledge being offered by others.

More significantly, what you describe is a process of deciding whether 
the person speaking is 'worthy' of their view, as opposed to a process 
of evaluating the view itself.

> as a whole it's more scattershot.

Actually, Section 2.5 is a really good example of problematic 
conflating.  The section defines its scope as "interpret[ing] the 
results of the check_host() function".

Yet Section 2,5,4 has /normative/ text about a specific form of 
reporting AND it points elsewhere for another.

The section should confine itself to its stated goal.  Discussion of 
reporting mechanisms should be separate and later.

> opinions are inherently equal.

Except "one person say[s] it is not" hasn't been asserted; this suggests 
that you've misunderstood the concern about document organization.

> I believe the guidance from the chairs has made discussion of most of my

oh?

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Sep 2012 16:10:46 -0700

> These premises also seem to me to be plausible, if perhaps not

1: I don't believe the proposed reorganization makes any changes to
the protocol itself (or if it does, they were identified for
discussion and not intended as a covert maneuver), so I find the first
argument unconvincing.

2: Given that there was one tweak to normative text I made in earlier
versions of the proposed reorganization (for discussion, I reiterate)
and that Scott found this pretty much immediately, I have no
misconceptions that anything could be "snuck in" by me or anyone else.
 In fact, Scott is probably the only one that could do that since the
rest of us don't have "the pen" and have to argue for consensus to get
things changed.  The SPF proponents among us are watching for those
very carefully already.  I also find that this premise presupposes
malicious intent by other contributors, and I hope we haven't reached
a level of distrust that would impede the potential for improving the
work.

3: I recognize the convenience of being able to use "rfcdiff" to see
what changed between two versions of a document, but I don't find that
convenience to be, on its own, large enough to outweigh the value of
potentially better presentation of the material.  We have enough
thorough reviewers among us, as well as several that will see this
before it reaches IESG evaluation (not to mention during).  That's a
pretty tight net indeed for catching changes, accidental or
intentional.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 17 Sep 2012 21:23:54 -0400

> for resolving a fundamental ambiguity in output semantics.

I'm glad to stop claiming the DKIM development process is a bad example as 
long as people don't claim it was a good one. 

> an implied requirement for doing a specific SMTP failure code.

This continues to mystify me.  If people are going to read "If you choose to 
do A, here is how you communicate that choice" as "You must do A", then 
there's no hope.  Whether the example belongs there or not, I think this is a 
poor reason t move it.  

It might better be in (from -07) the Section 9 discussion of local policy 
since there's where we discuss rejection, but I think it's useful to have a 
normative statement of what SMTP and enhanced status codes to use (since you 
can't unambiguously figure out the correct enhanced status code to use just 
from reading references).  So maybe it's better where it is.

I think there are reasonable alternatives here, but I don't think that people 
getting confused about rejection being required is a good reason to change 
anything.

snipped more DKIM references.

> > First, while it's generally problematic, the page you says states that is
> > is usually problematic because "either the Authority is not a
> > subject-matter expert, or there is no consensus among experts in the
> > subject matter".

I'm quite familiar with confirmation bias.

> repeats the problem of appeal to authority.

Not at all.

> it qualify as an appeal to authority?

It rejects my argument that I have appropriate expertise to have an authority 
position (i.e. this fits the exception case where it's OK) not by assessing the 
merits, but by referring to another authority and asserts that by definition 
any claim of authority is wrong.

> > issues.  I don't claim it's dispositive on it's own, but I think
> > operational experience and evidence should be weighed heavily.  I think
> > more than opinions of people who've just read the spec.
> 

I think it's reasonable, on the basis of a claim to expertise to discuss what 
expertise is relevant.  I believe that, while technical writing experience is 
an important expertise for this discussion, it is less significant than 
experience implementing RFC 4408 and with operational use of the protocol.

Running code is important.  http://www.rfc-
editor.org/errata_search.php?rfc=5965 is out there now because when I was 
participating in the MARF working group, I hadn't implemented it yet and so it 
wasn't until I starting trying to do so, I discovered the error.

> > I disagree.  It makes splits information about related topics up and makes
> > it harder to find.  For example, if you're interested in getting feedback
> > on your SPF deployment, 4408bis (both organizations) suggests two
> > methods.  In -07 they are together.  In the reorg, they are not.  I think
> > this is the opposite of clarity.
> 

Except I think it's fundamentally flawed, so moving to the new organization and 
then bug fixing it won't get back to as good as what we have now.

> > much less interested in comments grounded in lack of experience.  They
> > aren't all of equal value.
> 

If 5 people agree on something, but have little experience with the topic, but 
two people, who have great experience the topic disagree, then, while both 
views should certainly be considered and evaluated, I think it's more likely 
the two with experience will have the more correct view.

> > appendicies.  You may find each individual bit more coherent, but I think
> > that as a whole it's more scattershot.
> 

Or change the title to match the text.

> > If one person says a spec is usable and they've actually implemented stuff
> > from the spec and one person say it is not, but they haven't, I don't
> > think those opinions are inherently equal.
> 

Clearly there are several people on the list who believe the current 
organization is sufficiently deficient that it's worth making life more difficult 
for the known set of implementors to improve it.

> > I believe the guidance from the chairs has made discussion of most of my

At the time I wrote that, I read guidance == direction, so nevermind.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 17 Sep 2012 21:39:34 -0400

> These premises also seem to me to be plausible, if perhaps not

There is more to it than this.

 - While the draft may not be in the typical organization for a standards 
track document, I think that if the diff is in fact kept minimal, most 
questions about this can be sufficiently answered along the lines of "Yes, but 
our focus was minimal change to RFC 4408 and the organization didn't seem to 
be a literal error that we had to fix."  Once we reorganize it, all bets are off 
and we'll need to bring everything up to the current documentation standard.  
I think this is rather more than we set out to do and will take us longer and 
not provide end users benefit at all proportionate to the effort it takes to 
produce it.

 - Myself, I'm not particularly concerned about people sneaking something in.  
I am concerned that we're discussing removal of the small local policy 
elements that are present in RFC 4408 in conjunction with the reorg as if this 
were non-controversial, but no one is sneaking anything.

 - I am much more concerned with the impact of the reorganization on 
maintainers of SPF libraries that want to update them to match 4408bis when 
it's published.  If they are organizaed similarly, then this audience can 
easily compare (even if they don't directly diff the text) 4408 and 4408bis.  
If we do the reorganization, then I think we'll  need an appendix telling 
people what's changed (with another chance to get things wrong).

 - The proposed reorganization divides topics up (find the two options in the 
proposed reorg for getting feedback data on SPF deployment) in ways that are 
arbitrary and will be hard for implementers to follow.

 - The proposed reorganization is clearly a precursor effort to splitting the 
document in two.  I think that it will be much better to have one document, 
even if it's somewhat long, with proper anchors and links within it where 
needed than to be constrained to external links to a document with no ability 
to link to specific sections of that document (I've asked someone to tell me if 
I'm wrong about this limitation and no one has spoken up).  So I think that 
doing a pre-split to make the split easier is an error.

 - The organization of 4408bis has proven itself good enough to foster 
multiple independent, interoperable implementations.  So there should be a 
certain caution in monkeying with it.  In software and specification 
maintenance efforts I've been involved in, it has always seemed to me that 
change equated to risk and there ought to be a clear and substantial benefit to 
taking that risk.  RFC 4408 is provably usable as is.  Any alternative is not, 
so we should be conservative about what we do.

> what trade-offs they think are acceptable as a result.

Thanks for pulling this together and trying to sort it out.

Scott K

---

From: John Leslie <[email-masked]>
Date: Mon, 17 Sep 2012 21:40:42 -0400

> what trade-offs they think are acceptable as a result.

   Not sure I can help; but I'll give it a try...

> The proposed reorganization depends on three basic premises:
> - first, that the current 4408-bis draft has grown and is a little
>   unwieldy.

   I indeed find it unwieldy.

> - Second, it's not obvious that RFC 4408 was organized as well as
>   it could have been, nor even that it limited itself appropriately
>   for something that is on the standards track.

   I am not among those who think RFC 4408 approached the "ideal".

> - Third (and related to the second), this document is moving to
>   the standards track, and therefore material that isn't really
>   appropriate to a standards track document should either be removed
>   (possibly being moved into another document

   I find a lot of room for confusion about what portion is protocol
vs. what is advice for receiver policy & practices.

> conveniently, depends on three basic premises.
> - First, the WG is in effect chartered to move SPF from the
>   experimental to the standards track, making as few changes to
>   the protocol as technically possible along the way.

   Clearly the charter has language discouraging changes to the
protocol: presumably some folks wanted to avoid wandering in the
weeds. Alas, this doesn't work well.

   It's generally better to give folks with serious concerns some
other place to discuss them than to suggest they are bad people
trying, consciously or unconsciously, to impede progress.

   I freely admit to being concerned about a bunch of issues where
IMHO SPF failed the crispness test. I don't expect to fix them in
this WG -- at least not before rechartering. If I post something
about one of these when the issue comes up, it is not an attempt to
settle the issue now: it's an attempt to lay ground for fixing it
later.

> - Second, with large changes to the text, it is easy to make
>   accidental protocol changes that will go overlooked; it is
>   also possible for someone intending a change to the protocol
>   to "sneak one in" this way.

   "Sneak one in" is a paranoid attitute which should be strongly
discouraged.

   RFC 4408 was Experimental for several reasons: prime among them
was an IESG (of the time) perception that SPF had many rough edges.
We have a very different IESG today, but I expect them to read
carefully enough to discover some rough edges. If we have good
answers to how these can be fixed, I expect RFC4408bis to sail
through easily enough -- if we don't, the charter limitations
won't save us. (The charter limitations are there because the
proponents wanted them, not because the IESG wanted them.)

> - Third, by cleaving to the organization in RFC 4408, we make it
>   possible to compare the two documents easily, which defends

   The IESG won't be comparing diffs; and frankly the implementors
won't compare diffs either. The implementors will want a section
listing issues they should check in existing 4408 implementations.

   Hope this helps...

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 17 Sep 2012 21:44:13 -0400

> listing issues they should check in existing 4408 implementations.

Would you please clarify what you meant by this?  How does checking existing 
implementations tell anything about what's changed in 4408bis?  I'm confused.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Sep 2012 22:37:18 -0400

No hat.

> discussion and not intended as a covert maneuver), so I find the first

That argument (and your others about reorganized text) I think puts
the burden of proof in the wrong place.

Whenever you open a protocol to produce a new document for it, you run
the risk that there will be changes introduced to the protocol.  Some
of those changes will be intentional (e.g. we have decided to ditch
RRTYPE 99 in SPF).  But some of those changes will be accidental.

The more you change the document, the greater the risk that you will
introduce such an inadvertent change.  Worse, since it is the WG that
is performing this work, there is every possibility that the WG will
not notice that the change it is making might in future be read by
someone not familiar with the discussion in the WG as meaning a change
to the protocol.  We would not be the first people to make that
mistake.

Therefore, especially given our charter, the burden of proof that a
given alteration in no way unintentionally alters the meaning of the
overall document is not on those who wish to stick with the older
organization, but on those who propose the change.  Scott has been
making this argument in another form: RFC 4408 has in fact produced
independent implementations that interoperate.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Sep 2012 21:37:43 -0700

> premises seem to me to be at least plausible, if perhaps not

Just to be explicit, I think all of these are valid points and I
support them as reasons for considering the rearrangement of the work
to be a useful step.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Sep 2012 00:57:22 -0400

> support them as reasons for considering the rearrangement of the work

I don't disagree with any of these premises either.  I don't think that 
reorganizing (or potentially splitting) provides enough benefit to overcome the 
inherent disruptiveness of reorganizing.  If there's material that better 
belongs in a standards track applicability statement than a protocol document, 
I'm not opposed to renaming section 9 SPF applicability statement can focusing 
the here's how you do stuff information there.  I believe that would be much 
preferable to a stripped down document that's approximately sections 1-8 with 
stuff removed.  In other words, re item 3, if there's a lot of material that's 
inappropriate as the document is defined, then let's adjust the definition.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Sep 2012 22:07:37 -0700

> not provide end users benefit at all proportionate to the effort it takes to

I don't think the "minimal changes" thing can be used as an excuse to
leave SPF, as John Leslie just put it, "rough around the edges."  If
we can do a good job morphing the document into something stronger and
more appropriate for the standards track, I believe we really need to
take this opportunity to do so even if the cost is uncomfortable.

> people what's changed (with another chance to get things wrong).

This can be mitigated by doing another thing John suggested: Include a
"Changes since 4408" section.  You already have that, though it's
possibly more detailed that what would be needed to cover the
implementer audience you're talking about here.

> arbitrary and will be hard for implementers to follow.

They are hardly arbitrary.  They distinguish between what's critical
for the protocol to be interoperable and what amounts to guidance for
operators using the protocol.  That's a pretty meaningful division,
not an arbitrary one.

> doing a pre-split to make the split easier is an error.

This over-states one of the goals.  As I think I said when I first
proposed it, the reorganization makes it easier to see what text could
be split if the working group wants to go that way.  It would also be
fine to leave those sections in the same document if that earns rough
consensus.  The main value I see in the proposal is the separation
described above.

> so we should be conservative about what we do.

The due caution I exercised is in preservation of the original text,
apart from its ordering.  I'm not immune to the point that there's an
audience that "got" RFC4408 as-is.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Sep 2012 01:28:12 -0400

On Monday, September 17, 2012 10:07:37 PM Murray S. Kucherawy wrote:
> > questions about this can be sufficiently answered along the lines of "Yes,
> > but our focus was minimal change to RFC 4408 and the organization didn't
> > seem to be a literal error that we had to fix."  Once we reorganize it,
> > all bets are off and we'll need to bring everything up to the current
> > documentation standard. I think this is rather more than we set out to do
> > and will take us longer and not provide end users benefit at all
> > proportionate to the effort it takes to produce it.
> 

There were a lot of things going on related to SPF in 2005 that just aren't 
relevant today.  I don't think John's characterization of the IESG of 2005's 
views on it is strong relevant to what we need to do.

I have assumed that if the IESG didn't want us to do minimal changes, they'd 
have approved a different charter, but it's certainly not something I have a 
lot of experience with.

> > easily compare (even if they don't directly diff the text) 4408 and
> > 4408bis. If we do the reorganization, then I think we'll  need an
> > appendix telling people what's changed (with another chance to get things
> > wrong).
> 

Yes.  We'd have to have this, I think.  Of course then we run the risk of 
different parts of the document conflicting.

> >  - The proposed reorganization divides topics up (find the two options in
> >  the> 
> > proposed reorg for getting feedback data on SPF deployment) in ways that
> > are arbitrary and will be hard for implementers to follow.
> 

I think that's true for a very narrow view of interoperability.  If every 
email domain owner published an SPF record that said "v=spf1 ?all" and every 
MTA operator on the internet implemented SPF checking, there would be 100% SPF 
deployment and it would be fully interoperable based on what I understand your 
definition to be.

It wouldn't actually do anything though.

As long as operator goals aren't being met, then I don't think 
interoperability exists.  The kind of interoperability you're focused on is 
absolutely necessary, but I don't believe it's sufficient.

So I think there is a certain amount of arbitrariness about where you drew the 
line and how you sliced things up that will lead to more confusing and more 
problems, not less.

> >  - The proposed reorganization is clearly a precursor effort to splitting
> >  the> 
> > needed than to be constrained to external links to a document with no
> > ability to link to specific sections of that document (I've asked someone
> > to tell me if I'm wrong about this limitation and no one has spoken up). 
> > So I think that doing a pre-split to make the split easier is an error.
> 

I agree that overstates your immediate goals, but there's a high correlation 
between people I've seen argue for a split (of just flat removal of 
information) and those supporting the split, so while your statement is 
correct, I can also look more than one step ahead and see where this likely 
heads.

> > change equated to risk and there ought to be a clear and substantial
> > benefit to taking that risk.  RFC 4408 is provably usable as is.  Any
> > alternative is not, so we should be conservative about what we do.
> 

Getting the text right is important, but I think it's not sufficient.  I think 
we ought to start with a presumption that the current structure is adequate 
and only change it based on a really firm basis that it's going to improve 
understanding.

Just to be clear, I don't see anything in the structure of the reorganization 
that is outside the scope of what it's reasonable for the working group to 
consider, I just don't particularly see it helping that much.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 Sep 2012 09:52:03 +0200

>>>> 3. You appear to believe that changing document organization
>>>> somehow changes SPF syntax or semantics.  Please explain that
>>>> view.
>>> 
>>> No.  I think the reorganization makes it harder to understand
>>> things. It's the contemporaneous effort to expunge all mention
>>> of receiver policy that I believe changes things.
>> 
>> The proposal concerns reorganizing the text.  A proposal to
>> alter receiver policy language is -- or should be, IMO -- a
>> separate topic.
> 
> This continues to mystify me.  If people are going to read "If you
> choose to do A, here is how you communicate that choice" as "You
> must do A", then there's no hope.

Curiously, there's plenty of people reading it that way.  Is there any
hope that we admit it?

> Whether the example belongs there or not, I think this is a poor
> reason t move it.
>
> [...]
> 
> I think there are reasonable alternatives here, but I don't think
> that people getting confused about rejection being required is a
> good reason to change anything.

Let me ask the reverse question:  If that example hadn't been there,
would confusing people have been a good reason to add it?  And isn't
that a deliberate attempt at confusing people?

Having little experience with the topic, I think it's enough to look
at what was written in that place in previous versions of SPF to learn
what the example in question is trying to say.

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Sep 2012 04:49:23 -0400

Scott Kitterman <[email-masked]> wrote:
> Would you please clarify what you meant by this?

   I'm guessing you mean "IESG won't be comparing diffs".

   What I meant by that is that the IESG will properly look at RFC4408
as an Individual submission which received essentially zero review;
and will be looking at 4408bis de novo. Does it meet today's standards
for a Proposed Standard?

> How does checking existing implementations tell anything about what's
> changed in 4408bis?  I'm confused.

   That makes two of us... The second sentence was trying to say that
implementors of 4408 (not bis) will want a short section pointing out
things they should check in their existing implementations to ensure
that they are also compliant with 4408bis.

---

From: SM <[email-masked]>
Date: Tue, 18 Sep 2012 02:12:16 -0700

>proponents wanted them, not because the IESG wanted them.)

One of the effects of having a discussion is to have good answers to 
know a problem can be fixed.  It may happen that there are good 
answers explaining why a problem cannot be fixed.

>listing issues they should check in existing 4408 implementations.

Yes.

I'll borrow a line from Andrew; there are no hard and fast 
rules.  Andrew Thisell mentioned that any reorganization will burn a 
lot of time.  Dave Crocker mentioned layering.  There are multiple 
implementations of RFC 4408.  There aren't any implementations of 
4408bis.  This gets me back to John Leslie's comment about 
changes.  Here's the diff I looked at: 
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/rfc/rfc4408.txt&url2=http://tools.ietf.org/id/draft-ietf-spfbis-4408bis-07.txt 
Any work on a specification can introduce accidental changes.

The message [1] posted by Andrew asked participants to clarify what 
trade-offs they think are acceptable as a result.  My personal 
opinion is that it's not a matter of choosing between two 
alternatives.  I went through this thread and I did not find 
trade-offs.  Maybe I missed them.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Sep 2012 07:24:36 -0400

>that they are also compliant with 4408bis.

OK.  Thanks for clarifying.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 18 Sep 2012 04:21:10 -0700

Hi Scott,
>absolutely necessary, but I don't believe it's sufficient.

I'll comment on the IETF perspective as the draft is intended to 
document IETF Consensus.  This is the guidance provided in RFC 2119:

   "Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability."

It can be argued that the above takes a narrow view of 
interoperability.  Having the interoperability only does solve the 
problem.  In my short experience RFC authors usually follow the 
guidance in RFC 2119 for usage of RFC 2119 key words.  If I had to 
describe interoperability, I would say that it is about the required 
bits for two ends to "talk" to each other.  It takes more than that 
to solve a problem.  However, the interoperability aspect is no 
longer a problem to solve.  From an IETF perspective it is a step 
forward as the user can have a product from one vendor at one end and 
a product from another vendor at the other end.

I hope I am not mistaken in saying that all operators do not have the 
same requirements, i.e. there are different use cases.  I define what 
problem I am trying to solve and then see how to solve it.  I should 
also work on building consensus so that my proposed solution gains 
IETF Consensus.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 19 Sep 2012 01:40:27 -0400

> also work on building consensus so that my proposed solution gains

There are certainly varying use cases among operators, but there are general 
sets of goals that are reasonably common and the path to achieving them can be 
specified reasonably well.

I agree that it's a good thing to be able to have a product from one vendor on 
one end and another product from another vendor on the other end, but it's 
often not sufficient to make a protocol/system operationally useful.

I hope you noticed in the passage of RFC 2119 you quoted that there are two 
reasons given for use of RFC 2119 key words.  I'm glad you quoted it, because 
I think that the two elements of receiver policy that exist in RFC 4408 and 
that I believe need to be carried forward into 4408bis (SPF neutral MUST be 
treated the same as none and receivers SHOULD NOT reject based solely on SPF 
softfail) are both well within the scope of "limit behavior which has 
potential for causing harm".

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 25 Sep 2012 10:17:13 -0700

The current state of the discussion is a stalemate.  The WG can take 
up this issue at the next meeting as it is easier to find a path 
forward through face-to-face discussions.

Meanwhile, it is suggested that the WG addresses the existing issues.

Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs