Home | Sitemap | Recent Changes | Login |
Sender Policy Framework
Council Meeting/2005-11-20
|
On Sunday 2005-11-20 at 22:00 UTC, the council held a meeting on IRC. There was a pre-planned agenda. 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, 11-17) to the spf-discuss mailing list about the IETF status of the SPF internet draft, 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 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 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) be used for the council elections, as had been the case for the Official Project Domains community vote. 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 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 1 being a Monday and ranging from January 2nd to 8th:
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 on spf-discuss about an invalid application of the non-standard best guess processing by Gmail that seemed to have been inspired by the SPF project's own implementation, Mail::SPF::Query (M:S:Q), 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, a cleaner and more correct Perl module written by Shevek, 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 or trusted forwarder accreditation checking. Wayne and Julian believed that a reference implementation should not directly include non-specified features. However, Mark explained that there were indeed good reasons 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, 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. |
The SPF ProjectNews About Us DocumentationFAQ Support |
||||||||||||||||||||||||||||||||||||