-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
HTML: http://new.openspf.org/Council_Meeting/2005-11-20
- --------------------------------------------------------------------------
The Council Meeting on 2005-11-20
- --------------------------------------------------------------------------
On Sunday 2005-11-20 at 22:00 UTC, the council held a meeting on IRC[1].
There was a pre-planned agenda[2]. Greg, Julian, Mark, and Wayne were
present; Meng was absent for the most part.
Meeting minutes. Julian confessed that he had not managed to write the
outstanding meeting minutes yet, but that he intended to finish them before
the end of the sitting council's term so that they could be approved on the
sitting council's last meeting.
Chairman's report. Wayne had nothing to report, except that there had been
a request for more regular council meetings, and that he had sent updates
(2005-10-06[3], 11-17[4]) to the spf-discuss mailing list about the IETF
status of the SPF internet draft[5], which, he said, seemed to have been
deferred by the RFC editor due to the standing IESG appeals.
Executive Director's report. Meng was not present, so the Executive
Director's report had to be skipped.
Council elections. Following the discussion[6] on spf-discuss that had
been kicked off by Wayne about whether a new council should be elected or
the council body should be dissolved altogether, there were several issues
to be discussed by the council. The following summarizes the most
important points that were made during the discussion.
* Who should be allowed to vote. Greg suggested that the same criteria
as last year be used for defining the constituency, and Mark agreed.
Wayne countered that allowing anyone to vote who had ever been
subscribed to one of the project's mailing lists, being still
subscribed or not, might not be desirable and could even facilitate
ballot stuffing[7] due to changed e-mail addresses. Alternatively,
Greg proposed allowing anyone who was subscribed at a specific key
date, plus anyone who had posted within the last year even if not
currently subscribed. Mark wanted to only permit those who were
currently subscribed and thus showed a continued and minimum level of
interest in SPF, to which Greg, Wayne, and Julian agreed. Julian
suggested that the beginning of the election process should be taken
for the key date.
Then the set of mailing lists whose subscriber lists should be used was
discussed. Wayne proposed that the same set of lists as last year be
used. Greg intended all project lists to be used, however Julian
wanted just spf-discuss, and possibly spf-announce, to be used. Wayne
noted that spf-help had also been used in the first council election,
and that in any case he preferred spf-help over spf-announce, as there
had been several people who had been significantly more active on
spf-help than on the other lists. Mark agreed that those people should
be given a chance at participating in the election. Julian pointed out
that an announcement about the election would be sent through
spf-announce and thus reach most of the subscribers of the other lists
anyway. Concluding the issue, Greg said that he could see using just
spf-discuss as a single authoritative mailing list as long as the
eligibility rules would be announced well before the key date, so that
those who wanted to participate in the election could still subscribe
to spf-discuss.
* How the elections should be conducted. Julian had proposed that the
Condorcet Internet Voting Service (CIVS)[8] be used for the council
elections, as had been the case for the Official Project Domains
community vote[9]. No one had any significant objections, but Greg
pointed out that people who did not understand the system due to its
complexity might not be entirely confident of the results. However,
Wayne noted that there had not been any complaints with the domain
vote.
Greg also wondered whether the proportional representation[10] feature
of CIVS should be used. Wayne noted that proportional representation
was marked "experimental" by CIVS. Later during the discussion, Julian
pointed out that using proportional representation would preclude the
combination of non-candidate options, such as "Dissolve the council",
together with person candidates into a single election vote.
* How the elections should be scheduled. Greg, Mark, and Wayne agreed on
holding the coming council election in January 2006, and, in general,
future elections in the January of each year. Julian wanted good
reasons to be brought up for delaying the vote past 2005-12-02, to
which Wayne and Greg replied that there was insufficient time for
proper preparations, and that the Thanksgiving holiday was coming up in
the USA on 2005-11-24. Wayne's reasoning that at least a week was
required for each of nominations, acceptance of nominations and
discussions, and voting, was unanimously accepted. Wayne added that an
election officer would have to be appointed, and that a dispute period
after the end of the vote would be needed, too. Julian explained that
voting through CIVS effectively required voters to register through the
SPF project website in advance, so only the e-mail addresses of those
who actually wished to participate in the election would be fed into
CIVS. Greg then emphasized that the registration requirement would
have to be made clear in the election announcement.
Julian wanted the council term to always start before February, and
Wayne suggested that the election process (and each of the phases)
start on Monday but not on or before January 1st. Mark and Julian
pleaded for a short dispute resolution period of only two or three
days. Greg and Wayne suggested that members of the sitting council be
allowed to submit disputes but be excluded from voting on disputes
submitted by themselves. Julian recommended that the election results
be published directly after the end of the voting period, and that the
new term begin directly after the end of the dispute or dispute
resolution period. Finally, everyone agreed on the following schedule,
with day 0 being a Monday and ranging from January 2nd to 8th:
Days Action/Phase
------------------------------------------------------------------
0- 6 Appoint Election Officer, Nomination
0-13 Acceptance, Discussion, Registration
14-20 Voting
21-23 Dispute
21-27 Dispute Resolution
28 Start of Term
* Letting the plan be approved or the council dissolved. Wayne promised
to write a draft resolution and present it to spf-discuss for community
discussion. Julian suggested to include a clause in the resolution
requiring a formal community vote for changes to the resolution.
Everyone agreed that a community vote should be held before the end of
2005 to approve or disapprove the sitting council's proposal for the
council elections and the implied prolongation of the current term.
Annual report on the council's work. Julian proposed that a report on the
outgoing council's work be created as a courtesy to the community. Greg
and Wayne wondered whether a press release summarizing the year would be
worthwhile. Julian affirmed and explained that he imagined the report to
be just about a page long anyway. Mark said that he preferred to have a
report after the SPF specification achieved RFC status, but he acknowledged
that this could possibly take another year and that a closing report at
this time might still be useful. Greg noted that a report would be a good
handoff to the new council, and then volunteered to write the report, based
on the year's meeting minutes, which Julian promised to finish before
2005-12-24.
At about 00:45, Meng joined the meeting after he had left his airplane to
Denver.
SPF reference implementation. Following a thread[11] on spf-discuss about
an invalid application of the non-standard best guess processing[12] by
Gmail[13] that seemed to have been inspired by the SPF project's own
implementation, Mail::SPF::Query (M:S:Q)[14], it was discussed how the
project should react to the apparrent misunderstanding.
* Should there be a reference implementation, and is there really one
now? Wayne said that he did not consider any of the existing
implementations to be a reference implementation and that he was unsure
of whether a reference implementation was needed in the first place.
Julian disagreed and said that there should be one, and that M:S:Q was
and had been the de-facto reference implementation. Mark agreed that a
reference implementation was needed and that M:S:Q should continue
playing that role for now. Wayne agreed that M:S:Q had been treated as
the reference implementation for a long time, but he showed regret
about the fact, noting that there had been many deficiencies in M:S:Q
such as a lack of IPv6 support. Julian pointed out that Mail::SPF[15],
a cleaner and more correct Perl module written by Shevek[16], was
destined to become the new reference implementation in the future.
* Non-specified features. Consensus was quickly found on the reference
implementation having to conform absolutely to the specification, but
there were slightly different opinions about whether it should be
allowed to implement additional, non-specified features such as best
guess processing[12] or trusted forwarder accreditation checking[17].
Wayne and Julian believed that a reference implementation should not
directly include non-specified features. However, Mark explained that
there were indeed good reasons[18] to at least include such features in
the same distribution package, possibly as a sub-class.
With regard to M:S:Q, Julian pointed out that, even if it was currently
considered the reference implementation, it had also been the very
first SPF implementation and thus had changed with the SPF
specification over time and had been widely deployed. As a result, he
said, M:S:Q could not be deprived of its legacy features now, even if
they would not normally belong in a reference implementation, or
otherwise existing setups would break when upgraded. Wayne still
disagreed that M:S:Q should be considered the reference implementation
but agreed that the existing non-specified features should not be
removed or significantly changed now. Meng pleaded that those features
be left in M:S:Q, but disabled by default. Finally, after it was
verified that those features in M:S:Q were indeed disabled by default,
everyone agreed to leave them unaltered[19], though Wayne upheld his
view that M:S:Q not be treated as reference implementation. Greg
suggested that notes be added to M:S:Q's code and documentation about
the non-specified features.
Due to the late time, the "Project website" agenda item was left
unaddressed and the meeting was then adjourned at 01:17 UTC.
Julian Mehnle,
SPF Council Secretary.
References:
1. http://www.schlitt.net/spf/spf-council/2005/11/21_irc_log.html#20051120T2200
2.
http://archives.listbox.com/spf-council(_at_)v2(_dot_)listbox(_dot_)com/200511/0017.html
3.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200510/0008.html
4.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200511/0171.html
5.
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662
6.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200511/0021.html
7. http://en.wikipedia.org/wiki/Ballot_stuffing
8. http://www.cs.cornell.edu/w8/~andru/civs/
9. http://new.openspf.org/Community_Vote/Official_Project_Domains
10. http://www.cs.cornell.edu/w8/~andru/civs/proportional.html
11.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200511/0152.html
12. http://www.openspf.org/faq.html#guess
13. http://www.gmail.com
14. http://www.openspf.org/downloads.html#spfquery
15. http://search.cpan.org/dist/Mail-SPF
16. http://www.anarres.org
17. http://www.trusted-forwarder.org
18.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200511/0211.html
19.
http://new.openspf.org/?action=browse&diff=1&id=Council_Resolution%2F20&revision=5&diffrevision=3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDpf4OwL7PKlBZWjsRAqOpAJ9zlPTQ8Omu9sJQcPIW3x/89QtiMwCfamzs
y1qF5noUnobD+v6d4OvcsW0=
=d9Q0
-----END PGP SIGNATURE-----
-------
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