If I'm elected, there are quite a few thing that I would try to move
forward on.
First off, I see SPFv1 standardization as my top priority, I think we
need to focus on it, and I believe that working on other standards at
this will hinder this. For details, see below my "SPFv1 First"
position.
I strongly support the "SPF Community Position on SenderID" as written
on http://www.openspf.org/OpenSPF_community_position_v102.html and
have signed it. Since this document was (obviously) written before
the elections, one of my first tasks would be to bring this to an
official vote.
I believe that William Leibzon's poll[6] outlines what this elected
council should be. While the number of people who responded to the
poll were not as large as I would like, I think it does reflect the
community's positions. I will listen to what people tell me and try
to make sure that the council represents the entire SPF community as
it evolves.
I very strongly believe that we must have an open and transparent
council. I believe that secrecy has hurt SPF in the past and will do
more damage in the future. While I understand the need for
confidential information in some cases, I will resign from the council
if I find that council members are not disclosing non-confidential
information, especially if it is just to "distill wisdom" to be handed
down to SPF-discuss.
This commitment to open and transparent leadership is not something
new to me. I am involved in another organization, the NAWCC, and
several years ago, I helped get several petition candidates elected
when the NAWCC was acting in a closed and cabal-like fashion. They
have yet to recover the trust and repair the damage from being
closed. See NAWCC Candidate's page[7] and Platform[8] for other
examples of my support for openness.
I do not think this initial election can accurately reflect the
SPF-communities position for a long period of time. If new elections
are not held within the next 6 months, I will resign at that time.
I think we should operate with the minimal rules that the IETF uses
for working groups. At this time, I would oppose the use of Robert's
Rules of Order (revised) 10th Revision, or similar. I could be
convinced otherwise, but I like the KISS principle.
I don't think we all have to agree on everything, we don't even have
to like each other, but I do think we can work together.
-wayne
Details on my "SPFv1 First" position:
I will oppose working on other projects, including Unified-SPF, until
after the SPFv1 spec has been made an RFC, or at least going to the
IESG last call. From my understanding of the RFC process[1], this
should be possible to finish within 2-3 months.
I believe that the current SPF Internet-Draft[2] does not describe the
"SPF-classic" as I understand it and should be changed. I believe
that the documentation I created for libspf2[3] more accurately
reflects the existing SPF-classic specifications[4], but uses the much
improved wording and formatting done by Mark Lentczner.
I have posted a complete list of difference between these two
drafts[5], but it needs to be understood that I have proceeded in
writing my draft for the purpose of libspf2 documentation. Various
people have various objections to parts of my spec and a new
SPF-classic I-D would need more discussion and, likely, changes.
[1] The RFC process is described in
http://www.ietf.org/rfc/rfc2026.txt?number=2026
[2] See draft-lentczner-spf
http://www.ietf.org/internet-drafts/draft-lentczner-spf-00.txt
[3] http://www.midwestcs.com/spf/spf_classic_libspf2/draft-schlitt-spf-00.html
[4] http://spf.pobox.com/spf-draft-200406.txt
[5]
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0065.html
[6]
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0162.html
[7] http://www.midwestcs.com/nawcc/index.html
[7] http://www.midwestcs.com/nawcc/platform.html