Subject: [spfbis] WG Review: SPF Update (spfbis)

From: IESG Secretary <[email-masked]>
Date: Tue, 20 Dec 2011 09:18:05 -0800 (PST)

A new IETF working group has been proposed in the Applications Area.  
The IESG has not made any determination as yet. The following draft 
charter was submitted, and is provided for informational purposes only. 
Please send your comments to the IESG mailing list ([email-masked]) by 
Tuesday, December 27, 2011                             

SPF Update (spfbis)
-----------------------------------------
Status: Proposed Working Group
Last Updated: 2011-12-09

Chair(s):
 TBD

Applications Area Director(s):
 Pete Resnick <[email-masked]>
 Peter Saint-Andre <[email-masked]>

Applications Area Advisor:
 Pete Resnick <[email-masked]>

Mailing Lists:
 General Discussion:[email-masked]
 To Subscribe:	https://www.ietf.org/mailman/listinfo/spfbis
 Archive:	http://www.ietf.org/mail-archive/web/spfbis/

Description of Working Group:

The Sender Policy Framework (SPF, RFC4408) specifies the publication
of a DNS record which states that a listed IP address is authorized
to send mail on behalf of the listing domain name's owner.  SMTP
servers extract the domain name in the SMTP "MAIL FROM" or "HELO"
command for confirming this authorization.  The protocol has had
Experimental status for some years and has become widely deployed.
This working group will revise the specification, based on deployment
experience and listed errata, and will seek Standards Track status for
the protocol.

The MARID working group created two specifications for publication of
email-sending authorization:  Sender-ID (RFFC4405, RFC4406 and RFC4407)
and SPF (RFC4408), with both having Experimental status.  By using
IP addresses, both protocols specify authorization in terms of path,
though unlike SPF, Sender-ID uses domain names found in the header of
the message rather than the envelope.

The two protocols rely on the same policy publication mechanism,
namely a specific TXT resource record in the DNS.  This creates a basic
ambiguity about the interpretation of any specific instance of the TXT
record.  Because of this, there were concerns about conflicts between
the two in concurrent operation.  The IESG Note added to each invited
an expression of community consensus in the period following these
publications.

Both enjoyed initially large deployments.  Broad SPF use continues,
and its linkage to the envelope -- rather than Sender-ID's linkage
to identifiers in the message content -- has proven sufficient among
operators.  This concludes the experiment.

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.

The working group will also produce a document describing the
course of the SPF/Sender-ID experiment (defined in the IESG note
on the RFCs in question), bringing that experiment to a formal
conclusion.  No other work on Sender-ID will be done.

Finally, the working group will develop the proposed "scope"
extension found in draft-mehnle-spfbis-scope.

Specifically out-of-scope for this working group:

* Revisiting past technical arguments that were covered
  in the MARID working group, except where review is reasonably
  warranted based on operational experience.

* Discussion of the merits of SPF.

* Discussion of the merits of Sender-ID in preference to SPF.

* Extensions to SPF other than the one specified above.  The
  working group will re-charter to process other specific proposed
  extensions as they are identified.

The initial draft set:
	draft-kitterman-4408bis
	draft-mehnle-spfbis-scope

Goals and Milestones:

MMM YYYY:  A standards track document defining SPF, based on RFC4408 and 
           as amended above, to the IESG for publication.

MMM YYYY:  A document describing the SPF/Sender-ID experiment and its 
           conclusions to the IESG for publication.

MMM YYYY:  A standards track document creating the "scope" extension to 
           the IESG for publication.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 09:24:28 -0800

On 12/20/2011 9:18 AM, IESG Secretary wrote:
> Please send your comments to the IESG mailing list ([email-masked])

SPF is very widely used.  It has become a critical component in the anti-spam 
toolchest.

It's documentation needs refining and its technical details probably need 
refining.  An open, consensus-based process is needed for making these changes.

The IETF is by far the most reasonable place for this work.

I say the above in spite of not liking SPF and of having frequently criticized 
it quite publicly, due to it's path-based approach and the limitations this 
imposes.

However the reality is that it's wide use mandates having a good spec and the 
demonstrable community consensus around it; and I'm willing to contribute to 
that effort.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 12:51:27 -0500

> Tuesday, December 27, 2011
...

I support the proposed charter.  I prepared one of the proposed input 
documents for the working ground and am interested in continuing this work.

Scott Kitterman

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 13:00:51 -0500

> Tuesday, December 27, 2011                             

I support a SPF BIS project effort to codify RFC 4408 but I have a 
fundamental problem with new extension ideas that will fundamentally 
change the SPF protocol from a SMTP level only protocol to a RFC5322 
payload download requirement protocol.  Something that is not required 
in SPF and was specifically design not to have since the MARID days. 
This new protocol introduction violates the boundary layer, increases 
overhead and redundancy concerns and
increases security concerns - all of which was discussed during MARID 
and the reasons why SPF did not have a PAYLOAD requirement.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Tim Draegen <[email-masked]>
Date: Tue, 20 Dec 2011 13:01:11 -0500

> Tuesday, December 27, 2011                             

I'm an advocate for this technology, and believe the IETF where this work needs to happen.  SPF is already widely-deployed.

For context, SPF is cited in a 2007 document that prescribes how financial institutions can bring security to email:

  http://www.bits.org/
  http://www.bits.org/publications/security/BITSSecureEmailApr2007.pdf

Although it has taken a number of years to become widely deployed, *at a minimum* major financial services organizations are looking to build upon SPF.  Significant up-tick in adoption shows that the time is right to progress SPF:

  https://otalliance.org/news/releases/EmailAuthTPoint.html

Several reasons why this works needs to happen:
- Hesitation to deploy remains in some areas due to the Experimental state of the current SPF document.
- A whole lot of operational experience and deployment data has been gathered since the SPF and Sender-ID documents were released as Experimental.
- Bringing closure to existing Experimental documentation will produce documents that will inform future developments.
- Without such closure, the task of focusing development efforts to produce systems that take advantage of SPF's capabilities will remain unnecessarily hindered.

=- Tim Draegen
Director of Technical Strategy, Agari
Chair of the Online Trust Alliance's Email Authentication Committee

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 10:06:05 -0800

> 	draft-mehnle-spfbis-scope

The second document currently is:

    draft-mehnle-spf-scope-00

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 10:14:50 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Tuesday, December 20, 2011 9:18 AM
> To: IETF Announcement list
> Cc: [email-masked]
> Subject: [spfbis] WG Review: SPF Update (spfbis)
> 
> [...]

I support the current charter, enough that I was the primary author of it.  I'm also willing to co-chair, edit documents, review documents, or be a general participant.  I also echo Dave Crocker's comments that for me this is more about doing The Right Thing with respect to the status of SPF, and not that I'm a particular proponent of it technically.

I also find there is no basis for the concerns about fundamental changes to the SPF protocol.  The charter specifically proscribes these, though it permits the eventual creation of extensions, which are, by the very nature of anything called an "extension", optional.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 13:33:58 -0500

> I support the current charter, enough that I was the primary author of it.  I'm also willing to co-chair, edit documents, review documents, or be a general participant.  I also echo Dave Crocker's…

This is a fundamentally a problem. One must not have any BIAS and must 
believe in the technology in order to be the WG project leader.  Case 
in point....

> I also find there is no basis for the concerns about fundamental changes to 
> the SPF protocol.  

Thats exactly the problem.  You wrote the charter, you have a 
documented history on being a vocal SPF opponent. You will have a 
major problem in this WG with people who are long time early adopters 
and implementators of SPF who does not agree which items in the 
proposed charter.  You also have a history of filtering, ignoring, 
water down opposing viewpoints and thus I do not agree you qualify to 
be the chair for this proposed SPF BIG Working Group.

> The charter specifically proscribes these, though it permits the eventual 
> creation of extensions, which are, by the very nature of anything called an 
> "extension", optional.

But that is not an excuse to fundamentally change the protocol, 
violating the protocol SMTP level only framework to one that requires 
RFC5322 payload downloads - something that was 100% debates and 
restricted during 2003/2004 MARID working group producing the SPF RFC 
4408 document and reason the RFC4405 SUBMITTER SMTP extension to 
specifically address the AUTHOR-DOMAIN needs this new SPF extension is 
duplicating but without exposing the author-domain, thus requiring a 
payload download requirement.

You MUST have a understanding of MARID discussions and debates, the 
SPF history, the reasons it is a SMTP level only technology and why it 
is not a RFC5322 technology, and also be a believer of the protocol in 
order to be trusted as a chair and leader of this project.

---

From: Dotzero <[email-masked]>
Date: Tue, 20 Dec 2011 13:47:53 -0500

On Tue, Dec 20, 2011 at 1:33 PM, Hector Santos <[email-masked]> wrote:
>> I support the current charter, enough that I was the primary author of it.
>>  I'm also willing to co-chair, edit documents, review documents, or be a
>> general participant.  I also echo Dave Crocker's comments that for me this
>> is more about doing The Right Thing with respect to the status of SPF, and
>> not that I'm a particular proponent of it technically.
>
>
> believe in the technology in order to be the WG project leader.  Case in
> point....
>
>
>> I also find there is no basis for the concerns about fundamental changes
>> to the SPF protocol.
>
>
> Thats exactly the problem.  You wrote the charter, you have a documented
> history on being a vocal SPF opponent. You will have a major problem in this
> WG with people who are long time early adopters and implementators of SPF
> who does not agree which items in the proposed charter.  You also have a
> history of filtering, ignoring, water down opposing viewpoints and thus I do
> not agree you qualify to be the chair for this proposed SPF BIG Working
> Group.
>

Hector, I think your comments are fundamentally unfair. I have worked
with Murray in various working groups as well as in various forums.
While I haven't always agreed with him I have always found him to be
fair and straight forward. He is able to distinguish his positions as
a participant from his activity as a chair and I have absolutely no
problems with him being a co-chair for the working group. He is
knowledgable in the space, has significant experience in working on
drafts/RFCs. There have been instances over the years where I have
fundamentally disagreed with him on a point and he has been nothing
but straight forward and fair in his dealings with me.

> But that is not an excuse to fundamentally change the protocol, violating
> the protocol SMTP level only framework to one that requires RFC5322 payload
> downloads - something that was 100% debates and restricted during 2003/2004
> MARID working group producing the SPF RFC 4408 document and reason the
> RFC4405 SUBMITTER SMTP extension to specifically address the AUTHOR-DOMAIN
> needs this new SPF extension is duplicating but without exposing the
> author-domain, thus requiring a payload download requirement.
>

As far as I can tell there is nothing proposed for the working group
(spfbis) which proposes to "fundamentally change the protocol".
> You MUST have a understanding of MARID discussions and debates, the SPF
> history, the reasons it is a SMTP level only technology and why it is not a
> RFC5322 technology, and also be a believer of the protocol in order to be
> trusted as a chair and leader of this project.
>

I'm confident that Murray has an understanding of the MARID "discussions".
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 10:59:07 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dotzero
> Sent: Tuesday, December 20, 2011 10:48 AM
> To: Hector Santos
> Cc: [email-masked]; [email-masked]
> Subject: Re: [spfbis] WG Review: SPF Update (spfbis)
> 
> fair and straight forward. He is able to distinguish his positions as a
> participant from his activity as a chair and I have absolutely no
> fundamentally disagreed with him on a point and he has been nothing but
> straight forward and fair in his dealings with me.
> [...]

Thanks, I appreciate the support.

I am actually not an opponent of SPF; that's not what I said.  I simply don't do any work to support or advance it as an implementer, and have chosen instead to invest my time into developing DKIM and its friends.

One might also characterize me as being against HTTP and TLS by the same logic.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 14:11:16 -0500

> (spfbis) which proposes to "fundamentally change the protocol".

The mere introduction of a new attribute that fundamentally works only 
by downloading the payload is a fundamental change to the SPF 
protocol, regardless if its injected into the revised protocol under 
the guise of an "optional" logic.

Current implementations will apply SPF at the MAIL FROM or in smarter 
SPF implementations after the RCPT TO has been determining.  If this 
scope= is part of the DNS query for the return path domain, then its 
intent has one purpose - to direct the SMTP logic to move its logic to 
another layer where is most likely does not currently exist.

That is a fundamental change not only in SOFTWARE but in the framework 
of SPF.

> I'm confident that Murray has an understanding of the MARID "discussions".

If he did then he would sympathetic to the reasons SPF was designed as 
SMTP protocol and specifically design not to depend on any RFC5322 
information.  That what was RFC 4405, SUBMITTER, was for.

Anyway, A bias has already established towards people who are involved 
deeply with SPF, has a bias towards SPF itself and has already shown 
how he will disagree with participants where a chair MUST be open 
minded. He does not qualify to be a fair chair for this WG and it it 
will be very unfair to people that do not want RFC5322 methods 
injected into SPF or if reconsidered by them, to be very carefully done.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 20 Dec 2011 13:12:03 -0600

Folks, let's bring this down a notch, shall we? First, the IESG is 
looking for comments on the charter. The charter includes no assigned 
chairs yet, so there is no need to comment on the qualifications of any 
particular person for that position. Second, Murray simply volunteered 
to be chair; no AD has actually appointed him. If you have suggestions, 
for or against, regarding potential chairs, feel free to send them to 
me. On two specific items below:

On 12/20/11 12:33 PM, Hector Santos wrote:
> believe in the technology in order to be the WG project leader.

Two things here:

1. Everyone has their biases, for and against all sorts of things. What 
I care about choosing a chair is whether the person can reasonably set 
them aside and guide the WG fairly.

2. "Belief in the technology" is most certainly *not* a requirement for 
chair, and in fact I often find it is a *detriment* to being a good 
chair. Long stories aside, my experience has been that the best chairs 
have absolutely no "chips in the game" with regard to a particular 
technology, and experts in the field with strong beliefs in favor of the 
technology make lousy chairs.

So I simply think the above analysis is incorrect.

> Thats exactly the problem.  You [...] You will have a major problem in 
> this WG with [...] You also have a history of [...]

The above is *completely* inappropriate. Again, if anyone has opinions 
on particular candidates for chair, they can communicate them 
*privately* to me. But public personal criticism like the above has no 
place on this list, is disruptive to productive work, and will not be 
tolerated.

pr

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

---

From: SM <[email-masked]>
Date: Tue, 20 Dec 2011 11:15:24 -0800

>extension found in draft-mehnle-spfbis-scope.

The first two work items will generate their share of 
controversies.  I suggest removing the "scope" document from the list 
of work items to restrict the scope of the controversies at the 
initial stage.  Once the proposed working group has produced the 
deliverables that can bring closure to the SPF/Sender-ID debates, it 
can determine whether there are still any surviving WG participants 
to pursue work on extensions to 4408bis.

>         draft-mehnle-spfbis-scope

That should be:

   draft-kitterman-4408bis-00
   draft-mehnle-spfbis-scope-00

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 11:19:53 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Tuesday, December 20, 2011 11:15 AM
> To: [email-masked]
> Cc: [email-masked]
> The first two work items will generate their share of controversies.  I
> suggest removing the "scope" document from the list of work items to
> restrict the scope of the controversies at the initial stage.  Once the
> proposed working group has produced the deliverables that can bring
> closure to the SPF/Sender-ID debates, it can determine whether there
> are still any surviving WG participants to pursue work on extensions to
> 4408bis.

My own opinion on this topic is that the chairs could serialize the work just fine so that SPFbis itself is done first before any work on extensions take place, without having to go through the process of re-chartering.  We like to block on AD procedure as little as possible.  :-)

That said, I'm told the re-chartering process is relatively cheap, so I wouldn't object to this if people push the point and convince the ADs that it's necessary.

-MSK

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Dec 2011 12:22:25 -0700

On 12/20/11 12:19 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of SM Sent: Tuesday,
>> December 20, 2011 11:15 AM To: [email-masked] Cc: [email-masked] 
>> controversies.  I suggest removing the "scope" document from the
>> list of work items to restrict the scope of the controversies at
>> the initial stage.  Once the proposed working group has produced
>> the deliverables that can bring closure to the SPF/Sender-ID
>> debates, it can determine whether there are still any surviving WG
>> participants to pursue work on extensions to 4408bis.
> 
> My own opinion on this topic is that the chairs could serialize the
> work just fine so that SPFbis itself is done first before any work on
> extensions take place, without having to go through the process of
> re-chartering.  We like to block on AD procedure as little as
> possible.  :-)
> 
> That said, I'm told the re-chartering process is relatively cheap, so
> I wouldn't object to this if people push the point and convince the
> ADs that it's necessary.

A least one of the current ADs (moi) is a fan of the phased approach.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 20 Dec 2011 13:23:42 -0600

> That is a fundamental change not only in SOFTWARE but in the framework 

I believe this is a repetition of the content of your earlier message, 
correct? If so, may I ask you to clarify for the IESG:

Are you suggesting to the IESG that the "scope" extension be removed 
from the proposed charter?

(The rest of your message was more of the inappropriate personal 
criticism that I mentioned earlier and shall be ignored, given that you 
sent your message before I sent my admonition.)

pr

---

From: Tim Draegen <[email-masked]>
Date: Tue, 20 Dec 2011 14:24:24 -0500

> A least one of the current ADs (moi) is a fan of the phased approach.

Peter, I'm a bit thick.  Which of the two is the phased approach?

=- Tim

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Dec 2011 12:28:53 -0700

> Peter, I'm a bit thick.  Which of the two is the phased approach?

Phase 1: finish revisions to the core spec.

Phase 2: recharter, then work on extensions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 11:35:07 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, December 20, 2011 11:29 AM
> To: Tim Draegen

To complete the picture, rechartering involves circulating an updated charter that lists completed work and then describes proposed new work for that WG, which goes through a two-week request for feedback before it gets approved or modified based on that feedback.  So we'd have to go through that to add the "scope" extension back in later.

-MSK

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Dec 2011 12:39:27 -0700

> To complete the picture, rechartering involves circulating an updated charter that lists completed work and then describes proposed new work for that WG, which goes through a two-week request for f…

To be clear, I'm not yet saying that I think a phased approach is needed
here, only that in general such an approach can motivate a group to
complete its core work first.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 14:40:37 -0500

+1, work out the current SPF spec issues, codify the spec, based on 
the 9 IETF-MAN/VENDOR-YEARS history.

We need to keep in mind that back during MARID it was clearly 
envisioned that new PAYLOAD technologies will come and we always knew 
there would be a need to couple or augment the technologies.   That is 
why a few of use considered a SMTP extension called HEAD to allow a 
sender to send the RFC5322 header first.

But the principle reason why MARID started was because of the 2003 
SORBIG world wide eVirus attacks which exploited 100% the SMTP relaxed 
nature of MAIL FROM checking and used the ACCEPT/BOUNCE requirement at 
a two prone attempt to deliver the payload:

     1st the RCPT TO,
     2nd the MAIL FROM during the bounce.

So a key goal was to avoid any payload download which the original SPF 
clone CEP by Microsoft was promoting (changed to SENDER-ID).

The compromise was the SUBMITTER protocol which was a SMTP extension 
to pass the PRA as a MAIL FROM keyword.

     MAIL FROM: <id @ SENDER-DOMAIN.COM> SUBMITTER=[email-masked]

If the goal of this SCOPE= idea is to serve the same purpose, then we 
already have the SUBMITTER protocol and its definitely in use.

SM wrote:
> closure to the SPF/Sender-ID debates, it can determine whether there are 
> still any surviving WG participants to pursue work on extensions to 
> 4408bis.
> 
>> The initial draft set:
>>         draft-kitterman-4408bis

---

From: Derek Diget <[email-masked]>
Date: Tue, 20 Dec 2011 14:45:22 -0500 (EST)

On Dec 20, 2011 at 12:28 -0700, Peter Saint-Andre wrote:
=>On 12/20/11 12:24 PM, Tim Draegen wrote:
=>> Peter, I'm a bit thick.  Which of the two is the phased approach?
=>
=>Phase 1: finish revisions to the core spec.
=>
=>Phase 2: recharter, then work on extensions.

My vote for the group formation would have the initial charter just do 
phase 1.  (That is to have the proposed charter remove the three 
references to the "scope" draft.)

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 14:59:25 -0500

> from the proposed charter?

Yes. I believe the SUBMITTER protocol suffices the intent of the scope 
without download the payload.

This scope= extension is too limiting and only does what we 
intentionally and specifically did not want during the original design 
of SPF.  The reasons have not changed and the principle concern was 
encouraging the payload to be downloaded like SENDER-ID did.

However I do support that SPF needs "Helper Technology" and this was 
also discussed over at MARID and over the years with the development 
of DKIM.   For example, POLICIES that couple SPF plus DKIM with 
perhaps an advertisement of a DKIM scope in the SPF record.  These 
ideas were all discuss in MARID, including suggestions with CSV/DNA 
that may expose the properties of the domain.

In order words, give receivers a better reason to alter their SMTP 
logic to download the payload to do RFC5322 processing.

So yes, I agree with a phase approach to first codify on the pure SPF 
protocol, clean it up,  without the scope= idea and discussed what we 
learned to see how to augment technologies developed since then for a 
2nd phase.  Its not only SENDER-ID at RFC5322 but also DKIM now.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 15:01:48 -0500

On Tuesday, December 20, 2011 12:39:27 PM Peter Saint-Andre wrote:
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Peter Saint-Andre Sent: Tuesday, December 20, 2011 11:29 AM
> >> To: Tim Draegen
> > To complete the picture, rechartering involves circulating an updated
> > charter that lists completed work and then describes proposed new work
> > for that WG, which goes through a two-week request for feedback before
> > it gets approved or modified based on that feedback.  So we'd have to
> > go through that to add the "scope" extension back in later.

I don't think that needs to be a concern in this case.  There is a long 
standing group of core contributors to the SPF protocol that are strongly 
motivated to work on the core work, so I think some degree of parallelism is 
quite safe.  The extension piece needs to lag the core protocol update 
regardless, but I don't think the need for a lag is so great that it shouldn't 
start before the core work is concluded.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 20 Dec 2011 13:36:01 -0700

As an early adopter of and participant in SPF, I too support the 
proposed charter to bring RFC4408 from Experimental to Standards Track 
and am willing to assist with inputs where possible and appropriate.

Alan M.

On 12/20/2011 10:18 AM, IESG Secretary wrote:
>   Pete Resnick<[email-masked]>
>   Peter Saint-Andre<[email-masked]>
>
>   Pete Resnick<[email-masked]>
>
> Mailing Lists:

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Dec 2011 21:05:42 +0100

I support the creation of the new WG on the basis of the submitted
draft charter.  Updating SPF is a long overdue job and I believe that
moving RFC 4408 to standard track will benefit the community.  I'm
willing to contribute by reviewing proposed drafts.

With respect to whether to phase or not to phase
> Phase 2: recharter, then work on extensions.

I note that the draft does say *Finally*, which resembles phasing and,
paired with an appropriate choice of the dates displayed as "MMM
YYYY", can likewise motivate the group to complete its core work
first.  It is a question of convenience and I'm neutral on this point.