[spf-discuss] Re: SPF council: new elections or disolve?

> > > > > "Julian" == Julian Mehnle
> > > > > "Re: SPF council: new elections or disolve?"
> > > > >  Wed, 16 Nov 2005 01:39:25 +0000
    >> So, what do people want to see done?  Hold new elections?
    >> Disolve the Council?  Extend the Council members' terms?

    Julian> I think there is still a lot to do for the project.
    Julian> Quoting a few things from my platform[1] from the 2004-11
    Julian> council election[2]:

    Julian> 1. | Submit the final [SPFv1] spec to the IETF.

    Julian>     I don't think this can be taken as finished until the
    Julian>     SPF spec has an RFC number and the outstanding appeals
    Julian>     have been resolved.

    Julian> 2. | Develop and advocate SES, SRS, et al as equivalent
    Julian>     alternative | solutions to the forwarding problem
    Julian>     [...].

    Julian>     Unfortunately, this is something that we haven't
    Julian>     achieved.  As far as I can tell, the dissemination of
    Julian>     SES/SRS code in OS and MTA distros is worse than that
    Julian>     of SPF itself, and even the latter leaves a lot to be
    Julian>     desired.  In any case, the project at least needs to
    Julian>     develop an as- clear-as-possible vision of how to deal
    Julian>     with the forwarding problem, even if we choose to
    Julian>     follow the "forwarding is the receiver's business"
    Julian>     mantra.

    Julian> 3. | Make plans on what to do next. SPFv1.5? SPFv2?
    Julian>     End-to-end crypto | such as S/MIME? Domain-based
    Julian>     reputation systems (cf. SpamCop?)?

    Julian>     This is actually the _most_ important task, IMO, that
    Julian>     should be taken up by the SPF project.  Personally, I
    Julian>     think the project should...
    Julian> * create a successor of SPFv1 (be it called SPFv1.5,
    Julian>       SPFv2.1, or SPFv3) that builds upon the lessons that
    Julian>       we have learned from SPFv1, and that embraces the
    Julian>       other sender authentication methods like DKIM and
    Julian>       thus actually lives up to the term "Sender Policy
    Julian>       Framework" (yes, it may take a long time to get it
    Julian>       adopted, but I think it would be worthwhile), and
    Julian> * build a domain-based reputation system -- in concept if
    Julian>       not in implementation -- that finally allows SPF
    Julian>       (and authenticated sender domains in general) to be
    Julian>       used for fighting e-mail abuse.

    Julian> The project assets (domains) issue in itself should not
    Julian> justify the ongoing maintenance of the council, but IMO,
    Julian> in addition to continued PR, at least items 1 and 3 would
    Julian> benefit greatly from a steering group.

    Julian> So, personally, I think we should elect a new council.

    Julian> As for the organization of council elections, I think they
    Julian> can be easily conducted using CIVS[3] (the system we used
    Julian> for voting on the domain names).  Using ranked (Condorcet)
    Julian> voting we can even combine the election with a referendum
    Julian> about whether a new council should be instituted at all:
    Julian> just add "The council body should be dissolved" as an
    Julian> option next to all the candidates.  Then, if in the
    Julian> overall results this option ranks higher than all of the
    Julian> candidates, a majority of voters wishes the council to be
    Julian> dissolved.

    Julian> I also think that the council should decide on who should
    Julian> be allowed to vote, and that it should appoint a neutral
    Julian> election officer who oversees and conducts the election.

    Julian> Julian, an individual participant of the SPF project.

    Julian> References:
    Julian> 1. 
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0582.html
    Julian> 2. http://new.openspf.org/Council_Election/2004-11
    Julian> 3. http://www5.cs.cornell.edu/~andru/civs
    Julian> ------- To unsubscribe, change your address, or
    Julian> temporarily deactivate your subscription, please go to
    Julian> 
http://v2.listbox.com/member/?listname=spf-council(_at_)v2(_dot_)listbox(_dot_)com

FWIW I agree with each of Julian's points above.

        jam

-------
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

pgpisUFoOAhL5.pgp
Description: PGP signature