[To the SPFBIS WG, cc'ed on this message:

During the IETF meeting, I received a formal appeal of the chairs' 
interpretation of the charter, specifically regarding the removal of 
"unused" features. I want the WG to understand that this is a normal 
(albeit thankfully infrequent) part of our process. As it says in RFC 2026:

    Disputes are possible at various stages during the IETF process. As
    much as possible the process is designed so that compromises can be
    made, and genuine consensus achieved, however there are times when
    even the most reasonable and knowledgeable people are unable to
    agree. To achieve the goals of openness and fairness, such conflicts
    must be resolved by a process of open review and discussion.

Indeed, in this case, I had spoken informally to both the chairs and the 
appellants prior to the appeal being filed, asking that the chairs make 
an explicit and final call on their interpretation and asked the 
appellants respond to that final call by writing an appeal to me if they 
disagreed with it. Everyone involved thought this was a good idea; it 
avoided the WG "rat-holing" on what is entirely a process point, and it 
allowed everyone to get their thoughts written up in clear text so that 
we could figure out the right path forward. In fact, I think the process 
point raised in this appeal is an important one, and one for which there 
is a reasonable interpretation on both sides. I think using the appeal 
process was exactly the right thing to do in this case and I thank both 
the chairs and the appellants for handling this in a professional and 
personally agreeable manner. This message is a reply to that appeal 
(which I have included in its entirety below).

By the way: I had intended to publish the appeal itself to the mailing 
list much sooner. However, a bout of illness -- just a nasty cold -- and 
a broken primary computer caused me to be behind, getting me into the 
"I'm almost done with the reply; I'll just post it all together" cycle. 
I apologize for the delay.]

Dave, Murray, and John,

I have considered the appeal you sent 2 August 2012 regarding the WG 
chairs' (Andrew and SM) interpretation of the SPFBIS WG charter 
regarding the removal of "unused" features in the SPF protocol as it was 
moved from it's current Experimental document to the WG's Standards 
Track document. I have reviewed discussions from the WG mailing list 
archive, my archive of IESG messages, and messages I received privately 
in order to suss out the the intention of the participants and IESG as 
to the meaning of the charter text as well as the technical and 
procedural merit of choosing a path different from that of the chairs' 
decision. In summary: There was no obvious decision for me to make on 
this appeal, but I have concluded that the chairs' decision was the most 
reasonable interpretation of the charter text and that any problems 
associated with that interpretation can be safely addressed after work 
completes on the present draft. I therefore deny the appeal.

Details:

This appeal comes down to the basic question: What was the intention of 
the charter with regard to the words "unused features" and "existing 
features that are in current use"? Though the appeal does indicate 
generally that there might be negative consequences to leaving certain 
particular features in the protocol (i.e., that such features might not 
be able to be removed through future work because we have a history of 
leaving such things in and that we would end up with a Proposed Standard 
protocol potentially with items which are "known to be a bad idea"), I 
was not asked to consider the particular technical choices of the WG or 
the chairs. That is, even though I know that two features in particular, 
the PTR feature and the local-part macro feature, are what drove this 
particular appeal, you have not asked me to make a particular call on 
those features. Rather, I was asked the more procedural question of 
interpretation. I think this is fine: If another feature is discovered 
with similar circumstances, we would want the answer to the general 
question to be answered.

I reviewed mail from the SPFBIS mailing list, from the IESG, and 
personal correspondence. The SPFBIS mailing list archive is not at all 
clear to me with regard to intention. You and the chairs are correct 
that the general attitude was to make the "barest minimum of changes", 
which I admittedly took to include being as conservative as possible in 
the removal of features. However, you are also correct that the 
discussion was almost entirely centered around not having *additional* 
features added. There are some early notes that indicate Murray's belief 
that the charter was intended to "prevent rat-holing on any of the 
contentious stuff" 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00023.html> and 
that there was no need to worry about "fundamental changes to the SPF 
protocol" because "the charter specifically proscribes these" 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00091.html>. 
However, Murray provides us with no direct language about the intention 
of "unused". Dave did state his intention pretty clearly 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00080.html>, 
though this view was not universally affirmed in the messages that 
replied to his. Meanwhile, as you point out in footnote [2] of your 
appeal, Doug Otis did bring up the topic of the local-part macro feature 
during the "SPFis WG scope" discussion 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00061.html>, and 
discussion continued on that topic into the beginning of January. At 
that time, Alessandro Vesely said in one post 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00184.html>, 
"The current charter does not allow us to ban local macros...", 
indicating his view was that the charter prohibited removal of the 
feature. More recently, messages have indicated that at least some of 
the participants understanding of the intent was different. (For 
example, see this message from Scott Kitterman: 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg01925.html>.) So 
from the participants in the original discussion on the list, I can't 
come to a definitive conclusion regarding intent.

However, on the IESG list, the issue of "unused features" was 
specifically asked about. On 27 December 2011 (after the original 
charter text had gone out for IETF Review), Doug Otis had sent a message 
to the IESG list, reflecting concerns noted above regarding the 
local-part macros. Stephen Farrell replied that day, in part (quoted 
with his permission):

    I do wonder if the charter here should explicitly either a) allow
    removal of SPF features with the aim of improving overall DoS
    resistance, or b) exclude discussion of this issue [...]

    Deciding to include or exclude this while forming the SPFbis WG might
    in any case be a good plan (take the pain once up front, rather than
    having to fight the battle loads of times if the charter isn't
    explicit).

Discussion of this point took place on the 5 January 2012 IESG telechat 
<http://www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-01-05.html>. 
My commentary there was:

    Pete R: There's also the comment from Doug Otis about the local-part
    macro. I'm inclined to declare that out of scope, maybe after a
    recharter. That's not documenting current practice, but is an overt
    change.

Subsequently, on 1 February 2012, I distributed a new version of the 
charter to the IESG and the SPFBIS list 
<http://www.ietf.org/mail-archive/web/spfbis/current/msg00223.html> with 
some additional text that I and (I believe) the IESG intended to address 
this specific issue:

    [Specifically out-of-scope for this working group:]

    * Removal of existing features that are in current use.

    Discussion of extensions to the SPF protocols or removal of
    existing features shall only be discussed after completion of
    current charter items in anticipation of rechartering the working
    group.

Note especially that until this point (and particularly, after the 
discussion I cited above that conveyed people's intentions), the above 
text did not appear in the charter. And here, unfortunately, was the 
breakdown in communication: I never explicitly said to the list why the 
changes were put in, and nobody on the list ever asked about the 
changes, let alone commenting on them or their intent. A failure on all 
of our parts, no doubt.

But that leaves me with the history of the list not having a clear 
intent on the particular point, and the history of the IESG having a 
more clear intent. So far, that leaves me leaning toward the stricter 
interpretation that I believe the IESG had, and that the chairs stated 
in their message on the list.

During discussions of this appeal with the appellants, it was pointed 
out that people might have had the impression that the criteria for 
removal of features would be similar to what occurs when a document 
moves along the standards track (Proposed Standard to Draft Standard as 
described in 2026, or Proposed Standard to Internet Standard as 
described in 6410). However, neither document is terribly enlightening 
on this point, and in fact lends credence to the argument that extremely 
minimal use is sufficient to call something "used". In 2026, section 4.1.2:

    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

That is, if there are simply *two* independent interoperable 
implementations of a given feature, that is enough to leave the feature 
in. In 6410, section 2.2, it says that a document may advance if:

    (3) There are no unused features in the specification that greatly
        increase implementation complexity.

Here, features are allowed to remain even if they are completely unused, 
so long as complexity is not greatly increased. Neither 2026 nor 6410 
give criteria for what features *may* be removed, but there is certainly 
no requirement that features that are "almost totally unused" be removed.

Given all this, I conclude that it is perfectly reasonable to interpret 
the charter as meaning that the barest minimum of use is enough to leave 
a feature in, and that the intent of all involved is either inconclusive 
or leans a bit toward this barest minimum interpretation. As I said 
above, this was a failure of communication all around, and we need make 
sure that our intentions are clear in the charters we write in the 
future. Unfortunately, all parties relied on "special knowledge" of the 
meanings of the words we used (folks assuming that when we said "unused" 
it was a special meaning that would be understood by all, when in fact 
each group had a different meaning in mind), and we need to be more 
explicit in the future.

That leaves the question of whether it is reasonable or problematic to 
expect the WG to complete work on simply moving the protocol from 
Experimental to Proposed Standard and only then re-chartering to take on 
more controversial subjects like the removal or addition of features. 
You make two arguments for tackling the work of removing features now:

1. The IETF (among others) is historically unsuccessful at delaying 
known work to the future, and leaving such work for the future creates 
an "unstable market".

2. Leaving a feature in that is either a known bad idea or is relatively 
unused and complex would not stand review scrutiny for a Proposed 
Standard document.

I find the first argument completely unconvincing. First of all, we have 
many examples of charters that have future work delayed (though 
admittedly most of these are extensions rather than deletions), and they 
deploy successfully. The idea of an "unstable market" might hold a bit 
more weight for me if it weren't the case that the market is already 
quite stable in the case of SPF: There are many deployments that already 
have the features in question and no signs that such deployments are 
obviously problematic. I see no evidence that this delay in removal of 
this feature (if that is what is eventually decided) is going to have a 
significant impact on the deployment of this protocol, let alone "kill" 
the effort. (In response to your footnote regarding the new standards 
track with its reduction in number of maturity levels, I simply disagree 
with the analysis. The problem such a reduction addressed was *not* that 
Proposed Standards were always completely embedded in stone. Indeed, we 
continue to have incremental development and deployment as old Proposed 
Standards get replaced by new Proposed Standards, as 6410 rightly points 
out. The problem, I would argue, was that we had no incentive to 
document -- to the extent required by 2026 -- when a protocol had 
actually stabilized, and the new one-step advancement lowers the bar to 
declare something as having stabilized. I think we can, and do, continue 
to do reasonable incremental development and deployment.)

As to the second argument, I believe discussion has been curtailed on 
the merits of whether any of the features in question are "known bad 
ideas" or whether the complexity of the features in question is 
problematic. Indeed, as you state in footnote [2] below, whether there 
is an actual security problem with one of the features is "unverified", 
and as far as I can tell, the claim was at best controversial. So I 
think the IESG would have little room to claim that the feature should 
be removed on "known bad idea" or "security" grounds. Furthermore, I 
believe that from the above analysis of the intent of the charter, it is 
clear that the IESG did not desire the WG to do extensive analysis where 
such claims were not immediately obvious to the WG as "errors"; instead, 
the intention was to move the document properly to the standards track, 
with change control moving to the IETF proper, and then undertaking 
discussion of controversial topics at a later date.

(On two smaller statements: My conclusion is that this is not a "usual 
bis effort", as you put it below, in that the publication of the 
original protocol as Experimental was far from usual, and moving it into 
the standards track is equivalently not the normal such effort. 
Furthermore, though the number of implementations and sites using the 
features in question is quite small, it is entirely hyperbole to claim 
that this constitutes "that a single implementation has veto power over 
feature removal.")

In denying this appeal, I am willing to ask the IESG for clarification, 
making absolutely explicit in the charter the desire to leave these 
sorts of features in the protocol. However, I will refrain from bringing 
this to the IESG in case you wish to appeal my decision to the IESG as a 
whole.

I would ask that discussion of this decision be kept off of the sbfbis 
mailing list, as I'm afraid it will be a distraction to other work. If 
folks would like me to set up a mailing list for discussion, I'm happy 
to do so.

Pete Resnick
Applications Area Director for SPFBIS

On 8/2/12 2:27 PM, Dave Crocker wrote:

> To:    Pete Resnick / cognizant area director
> From:  Dave Crocker, Murray Kucherawy, John Levine
>
> Pete,
>
> { See below for notes on the distribution of this memo. [1] }
>
> RFC 2026:
>
>> 6.5.1 Working Group Disputes
> ...
>>    If the disagreement cannot be resolved in this way, any of the
>>    parties involved may bring it to the attention of the Area
>>    Director(s) for the area in which the Working Group is chartered.
>>    The Area Director(s) shall attempt to resolve the dispute.
>
> This is a formal appeal of the just-issued SPFbis working group 
> chairs' decision concerning scope of acceptable work:
>
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02010.html
>
> Their interpretation of the charter does not match the intent of those 
> of us who wrote it.
>
> Alternative wording is offered for the charter, to ensure that the 
> protocol revision effort is determined by pragmatic concerns, rather 
> than nuances and vagaries of vocabulary interpretation and rather than 
> relying on hypothetical futures that expect rapid repetition of 
> protocol revisions.
>
> http://datatracker.ietf.org/wg/spfbis/charter/
>
> The chairs have decided the charter's use of the word "unused" means 
> that certain items for possible removal from the specification are out 
> of scope, since their usage is merely "extremely low" rather than 
> "zero".  In this case "extremely low" has been empirically measured as 
> somewhere between zero and 0.5% of the large installed base for global 
> Internet mail infrastructure.
>
> The chairs' interpretation has blocked discussions that could simplify 
> the protocol and its implementation, as well as improve its 
> interoperability.
>
> The formal note from the chairs, explaining their decision, 
> acknowledges that it runs contrary to normal IETF practice for 'bis' 
> efforts:
>
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02010.html
>
>> We appreciate that this is not the way we as a community normally
>> proceed when advancing a document on the standards track.
>
> However the latter sentences in that paragraph provide likely insight 
> to the foundation for the current problem:
>
>> At the
>> time the WG was chartered, the aim was to move RFC 4408 to the
>> standards track with the barest minimum of changes.  This is why the
>> charter says in more than one place that we're not allowed to change
>> things that are in use.  We are not moving a document along the
>> standards track; we are converting from the experimental track to the
>> standards track, and we want to do that with maximal backward
>> compatibility.
>
> The issue is not whether your, their or our interpretations of the 
> word 'unused' is justified, but that the interpretations diverged.
>
> From recent discussions with you, we have learned that the chairs and 
> ADs had discussions about this extremely constrained interpretation of 
> the scope but did not pursue it with the rest of us who were active in 
> formulating the working group (and writing its charter).  Our own 
> interpretation during the charter-writing process was for the more 
> typical constraint that permits judicious removals.
>
> To emphasize, none of the predicates quoted above were discussed on 
> the group's mailing list.[2]
>
> From the recent discussions it appears that your own expectation was 
> that this working group effort would be fairly quickly followed by 
> another that dealt with "substantive" changes.
>
> This represents problematic thinking on at least two axes.  First, the 
> IETF -- and every other standards group -- has an extremely poor track 
> record when doing current work that is based on an expectation of 
> future work.  Second, any plan to do additional revisions anytime soon 
> creates an unstable market:  when the first round comes out, 
> implementers tend to delay adoption, waiting for the next round.  Such 
> a rate of change has classically killed many standards efforts.[3]
>
> Rather than being subtle or clever, at least some of us who were 
> writing the actual charter text intended exactly the usual constraint 
> on changes.  That is, protect the installed base while removing cruft.
>
> As cited in the above quoted text, apparently the background, 
> pre-chartering management discussions placed emphasis upon the SPF 
> specification's moving from Experimental to standards track, with the 
> view of having this justify deferring some technical concerns.  That 
> is, planning for substantive changes to be made in a later revision 
> effort.  However the idea of putting something on the standards track 
> that includes any (or both, in SPF's case) aspects known to be (a) a 
> bad idea, or (b) relatively unused complexity would typically be 
> expected to prompt an AD Discuss or vigorous SecDir criticism.
>
> In practical terms this was, again, a decision based on formalities 
> rather than pragmatism.  And it certainly was/is not relevant to 
> some/most/all of us who are involved in the actual use of SPF.
>
> SPF is a deployed protocol.  For more than six years, the global email 
> operations community has counted it as an essential tool in anti-abuse 
> efforts.
>
> The decision to first publish SPF as Experimental was entirely 
> reasonable at the time, in terms of IETF formalities.  However it is 
> important to distinguish between those IETF-specific, institutional 
> formalities from the real-world pragmatics of protocol use and 
> maturity.  That distinction appears to be missing in the current 
> working group management and its oversight.
>
> The SPFbis working group effort certainly does need to attend to 
> protection of the installed base, as the chairs and the rest of us 
> agree.  However, as is usual for IETF 'bis' efforts on deployed, 
> successful protocol efforts, this does not automatically mean that a 
> single implementation has veto power over feature removal.
>
> In order to ensure that the charter is interpreted according to 
> criteria common for conservative 'bis' efforts, while still permitting 
> reasonable changes, here are suggestions for alternative text:
>
>> Changes to the SPF specification will be limited to the correction
>> of errors, removal of unused features, addition of any enhancements
>> that have already gained widespread support, and addition of
>> clarifying language.
>
> should be changed to:
>
>      Changes to the SPF specification will be limited to the removal 
> of features that have had no significant deployment, removal of 
> features that have caused serious interoperability problems, addition 
> of any enhancements that have already gained widespread support, 
> correction of any simple textual errors, and the addition of 
> clarifying language.
>
> and
>
>>> Specifically out-of-scope for this working group:
> ...
>>> * Removal of existing features that are in current use.
>
> should change the bullet to be:
>
>    * Removal of existing features that have developed significant, 
> interoperable use.
>
> We look forward to timely resolution of this appeal so that the 
> working group can again attempt to refine SPFbis according to its 
> extensive field experience.
>
>
> /Dave Crocker
> /Murray Kucherawy
> /John Levine
>
>    [1]  Although an appeal to the IESG is quite public, nothing in the 
> formal process requires that an appeal to an AD be circulated 
> publicly.  In order to simplify the dynamics of this appeal, we are 
> sending it only to the ADs and Chairs.  You may, of course, choose to 
> circulate it further, but we don't feel that that's necessary for our 
> purposes.  If it happens that the charter changes recommended by the 
> appeal is approved by you, then that can be pursued purely as a 
> charter change, rather than an appeal, thereby avoiding the more 
> charged tone of an appeal.
>
>        And since Pete and I discussed it, I'll note that I tried to 
> make the From: field contain all the authors of this appeal.  Alas, 
> Thunderbird wouldn't let me...
>
>    [2]  The pre-chartering mailing list discussions that did take 
> place, with respect to issues that could be called "barest minimum of 
> changes", were actually focused on not /adding/ anything.  That's 
> where most of the contention was.  There was also some intent around 
> blocking an attempt to remove a specific feature, but that was because 
> the proposed removal was justified in terms of unverified security 
> concerns.  What we discovered later is that, threat or not, it is 
> almost totally unused. That's a far stronger basis for removing 
> something as it advances in status, in our view.
>
>    [3]  In fact predicating improvements on the notion of a follow-up 
> revision draft appears to fly in the face of the recent IETF effort to 
> reduce the number of standards track maturity levels.  The premise of 
> that work was realization that once something reaches Proposed 
> Standard, there is rarely industry interest in a further 'tuning' 
> exercise.  In the face of that standards track formal change, it runs 
> contrary to have current work plan for a successive revision for SPF.

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