Julian Mehnle wrote:
(There should have been more regular meetings. I as a
council member have been lobbying for regular if very
concise meetings for a long time. I think it would have
kept up the steam.)
+1 For the occasions when Meng was present his "CEO reports"
were often interesting. And there are about two months of
Council activities without published (= approved) minutes.
1. | Submit the final [SPFv1] spec to the IETF.
I don't think this can be taken as finished until the SPF
spec has an RFC number and the outstanding appeals have been
resolved.
+1 The first round of appeals is a mere formality, it boils
down to (for your appeal, Julian to Brian) "you should not
have approved senderid-core". One plausible answer could
be "but we did, for the details there's a huge IESG note".
William's appeal is more tricky, it boils down to "PRA
cannot really work for 'resend', period." But they (IESG)
could still say "nobody cares about 'resend', see 2476bis."
In both cases they (IESG) simply check what they've done.
They won't like to say "oops, we got it wrong", and they
might try to dodge it. In that case it's up to a second
round to get an independent 3rd party (= the IAB) on board.
I think the project should...
* create a successor of SPFv1 (be it called SPFv1.5, SPFv2.1,
or SPFv3) that builds upon the lessons that we have learned
from SPFv1, and that embraces the other sender
authentication methods like DKIM
No "EEE" please, poor DKIM has Doug, add SPF, and it breaks by
the combined additional weight... ;-) But I'd really like to
push SPF over the PS hurdles. Among other things that needs as
you said some "lessons learned" informational RfC, an updated
SPF test suite in some semi-formal language (not pure perl),
submit implementation and interoperability reports to the IETF
(for that we probably have to identify a set of "SPF features")
and finally tackle PS somehow:
- either as independent group (like Jabber), and then we better
revisit the question of an "IETF liaison" or some joint list
- or as a proper IETF WG (like DKIM), with a BoF etc.
* build a domain-based reputation system -- in concept if not
in implementation -- that finally allows SPF (and
authenticated sender domains in general) to be used for
fighting e-mail abuse.
A less ambitious plan would be to join forces with SIQ.
As for the organization of council elections, I think they
can be easily conducted using CIVS[3]
^^^^^^
You're in the position to know how "easy" that really is. I'm
positive that counting maybe 40 votes submitted by mail can be
done manually if necessary. It's no rocket science.
Just get one or two SPF Council meetings to decide about the
details. It's no problem at all if the election is in January
or late December, no need to rush it.
Obviously there is "rough consensus" to do it. Only the Chair
(= Wayne) disagreed, but his opinion that he doesn't need the
Council to check what he's doing as an individual is somewhat
beside the point... <g>
Bye, Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com