This is the recent traffic on the #SPF-council IRC channel on irc.pobox.com. Anyone may join the channel, but only council members can talk.

If you do not have access to IRC, you may view the recent traffic at: http://www.schlitt.net/spf/spf-council/now/irc_log.html.

This log can be can be viewed at: http://www.schlitt.net/spf/spf-council/2006/03/11_irc_log.html.

IRC nicknames:
JulianJulian Mehnle
MarkKMark Kramer (asarian-host.net)
SDGathmanStuart Gathman
shewMark Shewmaker
willixWilliam Leibzon
 
freesideMeng Weng Wong
gconnorGreg Connor
grumpyWayne Schlitt

--- Wed Mar 1 07:16:08 UTC 2006 ---
07:16<freeside>hey wayne
07:16<freeside>how you doing.
07:16<freeside>what's the status of the rfc thing?
--- Thu Mar 2 00:32:04 UTC 2006 ---
00:32<freeside>http://rtg.ietf.org/misc/auth48_limit
--- Tue Mar 7 16:32:38 UTC 2006 ---
16:32<shew>I can also make Saturday for the meeting.
16:32<shew>Not as convenient, and I hadn't edited my availability out that far, but it's sounding like that might be the most convenient for others.
16:44<Julian2>Hmm.
--- Sat Mar 11 14:02:34 UTC 2006 ---
14:02<shew>Morning.
14:03<Julian>hi SDGathman, hi shew
14:03<Julian>grumpy: ping
14:03<Julian>(...not that I'd expect him to reply...)
14:04<Julian>w00t!
14:04<Julian>hi willix
14:05<willix>too early?
14:05<Julian>No, right on time.
14:06<willix>ok then, I'll make that line statement of how I feel...
14:07<Julian>willix: Why didn't you request a later time for the meeting? I sort of waited for you to do so...
14:07<willix>later time for me would be too late for you
14:08<Julian>Would it? It's 15:00 local time here.
14:09<willix>slightly - i.e. 7am
14:09<SDGathman>I think our council members cover a timezone range of 8 hours.
14:09<Julian>We could have met two hours later or so.
14:10<Julian>Guys, please put your time and timezone info on http://new.openspf.org/Council_Members/Real-time_Availability
14:11<willix>I do get up for work at 7:30 am though, so its not too bad, but on friday I work late night because 11pm-3am is network mintanence window
14:11<willix>(lowest activity if traffic is largely us-centric then)
14:11<Julian>Ok, let me put up a consolidated agenda for this meeting...
14:12<willix>do we have a quorum?
14:13<shew>Here.
14:14<Julian>Any last-minute additions to the agenda?
14:15<SDGathman>none here
14:16<Julian>Ok, let's get started.
14:16<shew>none here either.
14:16<willix>Julian, can you call meeting to order then
14:17<Julian>I formally call the meeting to order.
14:17<Julian>willix: Did you manage to write last meeting's minutes?
14:17<Julian>(Yeah, i still have some outstanding minutes to write myself...)
14:18<willix>No, I started on it, but went to sleep.
14:18<willix>I'm going to finish this weekend
14:18<Julian>Ok, no worries.
14:18<Julian>First item:
14:18<shew>(Oh, asking if anyone knows how to contact wayne for auth48 updates should be in the agenda somewhere. I think it's implied in (2).)
14:19<Julian>1. Reports.
14:19<willix>The only report is probably IAB appeal, which is next item...
14:19<shew>Nothing to report here.
14:19<Julian>(John A. Martin pointed to the schlitt.net WHOIS record. There's phone number there, I think.)
14:19<SDGathman>Good news that IAB appeal didn't delay RFC much.
14:20<Julian>Well, let's stay with the reports for a minute.
14:20<Julian>I'll start.
14:21<Julian>I can report that I have received the IAB response. I have also published the HSARPA "Cheeseplate" proposal I received from Meng, minus the resumes of Shevek, Wayne, and Mark K.
14:22<Julian>I also asked Meng to forward me the notification he has received from the RFC Editor about the edited RFC draft. Meng forwarded it to me and it contains a reference to the edited RFC draft (complete with RFC numbers etc.).
14:23<Julian>I have sent Meng another mail today asking whether he deems it appropriate for us to _publicly_ post it to spf-discuss. Still waiting for a reply, though.
14:23<willix>which RFC# are we getting?
14:23<shew>I'm assumming it doesn't include the changes Wayne was planning on doing.
14:23<shew>(I don't think it's appropriate to say the number here btw, until Julian gets a reply at least.)
14:24<Julian>re RFC number: I'm not sure just yet we should disclose that publicly.
14:24<willix>I'm under the impression that Wayne applied some of the changes before already
14:25<Julian>re Wayne's last minute changes: No, it doesn't include those. Unfortunately only Wayne has the complete list we compiled, so we need him to proceed. But we need him anyway because he needs to OK the draft independently from Meng (who seems to be reactive ATM).
14:25<willix>You're being overly catious about RFC#, but I guess if you feel so strongly about it send copy of the edited draft to spf-private
14:26<Julian>If I don't get approval from Meng to post the RFC Editor's notification with the link to the draft RFC within the next ~36h, I'll post it to spf-private.
14:26<willix>Do you want council members who are in US to try to contact Wayne by phone?
14:26<Julian>That would probably be better than me trying to contact him, I guess.
14:27<Julian>Who could do that?
14:28<SDGathman>I could try.
14:28<willix>Has wayne been seen in #spf channel at all lately?
14:29<Julian>SDGathman: Great. Do a WHOIS on schlitt.net, and try to call Wayne's number that's there.
14:29<shew>I'm in Atlanta. I could do it as well. (Though not for a bit today--at the end of recovering from a cold and going back to sleep after this meeting.)
14:29<shew>But I won't duplicate effort--no point for this. Would be great if you did it SDGathman..
14:29<Julian>shew: Oh, get well soon!
14:29<shew>Thanks.
14:30<Julian>SDGathman: Thanks for the effort. If you manage to get him on the phone, please ask him when he'll become reactive-by-email again.
14:30<SDGathman>WHOIS says it is registered to "disorganized" :-)
14:30<Julian>willix: Wayne has been idling on #spf and #spf-council for ages. Hi grumpy! ;-)
14:31<Julian>SDGathman: Yeah, that one.
14:31<shew>Hmm. Wayne's info here says he's using a server "london.irc.perl.org"..
14:31<Julian>That one's connected to irc.pobox.com.
14:31<Julian>Hi grumpy!
14:32<Julian>grumpy is Wayne. But he's idle, as I said.
14:32<Julian>Ok, on another note, I have started a discussion on spf-discuss about another version of SPF.
14:32<Julian>I guess you noticed it.
14:33<Julian>I'm sure I forgot one or two minor things, but that's all I can report right now.
14:33<SDGathman>Left a voice message.
14:33<Julian>Cool, thanks.
14:33<shew>Cool.
14:33<Julian>Oh, and I released Mail::SPF::Query 1.999(.1), and it is in Debian/Testing now.
14:33<shew>(I'm wondering if he's off travelling, what with seemingly using a london server.)
14:34<shew>All right.
14:34<Julian>Does someone else have interesting things to report (even if theoretically already known to the public)?
14:35<shew>Nothing to report here.
14:35<SDGathman>What happens if Wayne was in a plane crash or something?
14:36<Julian>Then we'll all be very sad, and Meng will have the sole control over the draft.
14:37<Julian>Ok, no further reports, it seems.
14:37<Julian>Next item:
14:37<Julian>2. Brief discussion of the IAB appeal outcome.
14:37<willix>theoretically if one of the authors is not contactable, the other author(s)s ok will be enough together with ok from IESG AD
14:38<Julian>I assume everyone has noticed the IAB response, right?
14:38<SDGathman>Yes. Bad news, good news.
14:38<Julian>So, what are your thoughts?
14:38<shew>Yes.
14:38<willix>I was expecting something like this response.
14:38<Julian>I was surprised by the simplicity (I wouldn't say elegance) of their argument.
14:39<Julian>But it is undeniable.
14:39<willix>IAB could decide on technical ground, but as I said they will be a lot more likey to only deal with procedural issues
14:40<Julian>The one thing in their response that I would dispute is that the IESG had given due consideration to the issue.
14:40<Julian>Anyway, the decision has been made. I think it was good to try the appeal.
14:41<shew>I appreciate that the logic and reasoning in the response lessons the political controversy. At the very least that allows us to more easily address the incompatibility issue in an announcement press release in a less, err, controversial way.
14:42<willix>At least it went fast. Lets put this issue to rest now.
14:42<Julian>I think the only way we can address the incompatibility now is to supersede v=spf1 and spf2.0.
14:42<Julian>Other than that, there's nothing we can do.
14:43<Julian>No dissent? Wow.
14:43<shew>I'm in agreement. :-)
14:44<willix>SPFng has always been the way to go. Question was if we can do it working with MS or not
14:44<Julian>Good point.
14:45<SDGathman>SPFng is also a good time to require type99.
14:45<willix>(MARID was really best attempt at doing that actually)
14:45<shew>The only thing I don't like is the..distraction that comes from everyone wanting to spend time on the much-more-fun brainstorming-type work of a newer standard.
14:46<Julian>Any other thoughts on whether/how we should react to the IAB response? I think we should at least send a short response to the IAB, IESG, and the IETF mailing list expressing our thanks for their consideration of the issue and our view of the situation.
14:46<willix>There is nothing bad about brainstorming. SPF was originally born this way and gained momentum and actvity from active participation. With RFC issue at rest, we'd have time for such work to be done with good background on what is good and bad
14:47<Julian>"much-more-fun" than _what_? Do you think we're not spending enough time on other, more important issues? Honestly?
14:47<shew>Well, I know I'm not spending enough time as I should on updating the new.openspf.org site. :-)
14:47<Julian>Heh, I know what you mean. ;-)
14:47<shew>And I will be distracted by more-fun brainstorming.
14:48<shew>Oh, I thought reaction was in agenda item 3 or 4.
14:48<SDGathman>Some people prefer brainstorming. Others prefer dotting the i's and crossing the t's. We need both types.
14:48<Julian>I have been working on a useful improvement of the Wiki software for the past weeks, that's why I have not done a lot of other work on the website. :-|
14:49<Julian>shew: Agenda item 4 is about announcements. I mean a simple reaction to the IAB decision, that's separate.
14:49<Julian>Ok, it seems there is no demand for further discussion of the IAB decision at this time.
14:49<shew>Oh, okay. Well, I agree on the idea of a response-to-the-response, as a separate thing from a note to spf-announce
14:50<shew>Should those wait until after rfc publication?
14:50<Julian>If there's anything else you want to say WRT the IAB decision, type "..." quickly.
14:50<willix>I've been thinking about announcement and it might be better to do info on appeal and publication of RFC together.
14:52<willix>As well as separate announcement regarding new council and direction for this year (kind-of together as well)
14:52<Julian>Ok, let's move on to the next item:
14:52<Julian>"3. Trying to agree on a basic common agenda for the next few months -- next steps?"
14:52<willix>Sorry - skipping ahead :)
14:53<Julian>Someone (I think William) had suggested that we discuss the common basic agenda on spf-discuss, but it hasn't happened.
14:53<Julian>Does everyone still agree that defining a common basic agenda should be done?
14:53<willix>Your message last night would be good start
14:53<Julian>Well, working on SPFng is only one part.
14:53<shew>On item 3: I still think updating the website and moving new.openspf.org over is very important. (Is there any way we can do the transition before spf-draft-is-plublished announcements go everywhere?)
14:53<Julian>Hrrm. Does everyone still agree _that_ defining a common basic agenda should be done?
14:54<Julian>I do anyway.
14:54<shew>Well, I should remind folks of http://new.openspf.org/auth/Project_Agenda :-)
14:54<SDGathman>In addition to the website, I see the test suite and reference implementations as very important.
14:54<Julian>shew: Thanks for the reminder.
14:55<Julian>Do you want to discuss the _contents_ of the common agenda right now? (Just asking, I'm not opposed as long as it doesn't take us too long.)
14:56<Julian>If we don't want to do that now, we need to agree on a means to do it elsewhere.
14:56<willix>I think we want to add to agenda working on new version of SPF
14:56<Julian>Ok, let's try to discuss the agenda right here and now.
14:57<shew>I see discussion similar to the http://new.openspf.org/auth/Project_Agenda in the sense that a discussion of things-to-do or recognized-common-agenda is different from what we decide is our official order-of-importance.
14:57<Julian>Good.
14:57<shew>IMHO the latter should be a smaller list that we all agree on to a great extent.
14:57<willix>yes, order of importance is more time-specific
14:58<Julian>What are your thoughts on whether a new version of SPF should actively worked on (i.e. more than simple brain-storming and discussion, which can always happen without council approval)?
14:58<shew>I just added the new version to the "loose collection of outstanding tasks" list.
14:59<Julian>We need to compile the focused (non-loose) list.
14:59<shew>But I don't think that should be part of the official agenda yet, at least while it's at the brainstorming stage.
14:59<Julian>Ok. What do the others think?
15:00<willix>new website, work on new version, support of existing and new publishers, reference implimentation an test suite
15:00<Julian>Very good items.
15:00<shew>Perhaps I'm using different terms and vocabulary. When I think of official near-term agenda, I think of things like writing a response to the iab, writing announcement emails about publication of a standard, etc. ie, primarily things that must be done in the short term, and then will be removed from the list.
15:01<willix>That is called
15:01<willix>todo list
15:01<Julian>I think the agenda should be more mid-term.
15:02<shew>Hmm. Thinking on that.
15:02<Julian>Like, 1. get SPFv1 RFC published, 2a. create implementation-independent test suite, 2b. create new reference implementation, 3. get SPF included in MTAs proper and in OS distros, ...
15:03<willix>I thought of the agenda in more general way. This is what council would do in its leadership role.
15:03<willix>Where as near-term items is what council would do in the executive role
15:03<shew>What does putting "reference implementation and test suite" in the agenda of spf-council mean? I didn't think of writing another library as part of what the Council would do as part of it's council work, but as what folks would generally do on their own..
15:04<Julian>No, I wouldn't call it "agenda of the SPF council", but "SPF project agenda".
15:04<Julian>Tasks that the council needs to coordinate -- not necessarily do itself.
15:05<Julian>The council is here to lead, not to do all of the work on its own (which it cannot hope to do anyway), after all.
15:06<willix>Ok. Agreed. So I guess the question is if discussions right now should be on only on "agenda of the SPF Council" and if we should have separate item for this or future meeting to discuss "SPF project agenda"
15:06<shew>Oh! I was thinking of things that while the council might coordinate, we'd still do if no one else did. Writing faq items and such falls under that, while writing new libraries doesn't. If this is more of what-is-important-for-the-project-as-a-whole, then I see your points much more clearly.
15:06<SDGathman>I had in mind approving an existing implementation.
15:06<SDGathman>Not writing a new one.
15:06<shew>Me too. :-)
15:06<Julian>Well, that's fine too.
15:07<Julian>I smell someone liking the Python implementation. ;-)
15:07<shew>But the principle is the same. I considered it rather rude to say, for instance, that one of my goals is for Julian to continue his reference libary updates. :-)
15:07<willix>I'm generally against having council work on particular implimentation. I'd feel better if we simply had a well known one or more that is known to be 100% compliant and test suite to check others
15:08<SDGathman>We have a Perl, 2 C libs, and a Python implementation.
15:08<Julian>I have merely taken on the duty of maintaining M:S:Q while it is (hopefully) going to be phased out in the next few months as Mail::SPF reaches maturity.
15:08<SDGathman>Make that 2 Perl.
15:08<Julian>(I haven't really done that from my position as a council member.)
15:10<shew>I've updated http://new.openspf.org/auth/Project_Agenda
15:10<Julian>So, is everyone clear on the idea of a basic project agenda? Do we want to compile one here and now? Or somewhere else, like on spf-council?
15:10<willix>How about we discuss this on council mail list?
15:10<shew>I would suggest at least adding any other items to the loose-collection list on the above link.
15:10<shew>adding them at the moment.
15:11<Julian>shew: Thanks. However I don't think we should have multiple test suites. There needs to be only one. If a better one shows up, we could switch or merge, but we shouldn't have serveral ones with potential for conflict.
15:13<willix>yes, one test suite is best
15:13<shew>Updated to "Maintain lists of reference implementations and maintain an official blessing of one of them."
15:13<shew>oops.
15:13<shew>wording works better for the test suites.
15:13<shew>rewording..
15:13<shew>But other things to add now?
15:13<Julian>I'd like to propose "Get SPF into MTAs proper and into OS distros." and "Do a grassroots "Spread SPF!" campaign to get in touch with domain owners and ESPs/ISPs."
15:13<willix>btw - I may have to leave, my laptop is out of power and is not chargin
15:14<Julian>willix: :-(
15:14<Julian>willix: When can you be back?
15:14<Julian>...online I mean?
15:15<shew>added
15:16<Julian>Any other suggestions?
15:16<Julian>I think we can then compile the focused project agenda from the loose list of tasks on spf-discuss, right?
15:17<willix>Lets try to finish it in 10 minutes. If not I can probably come back in 20 minutes, but it may well be too late
15:17<Julian>Finishing in 10min will be difficult.
15:18<Julian>willix: Can you try to be back in 20min in _any_ case and tell whether you'll be able to stay or need to go offline entirely?
15:18<shew>I would like to reiterate the notion of moving the site being something that should be done soon.
15:18<SDGathman>Take a coffe break - then resume in 30 min with willix on new/refreshed machine?
15:18<Julian>Yeah...
15:19<Julian>Let's continue until willix has to leave, and then make a coffee (or tea) break.
15:19<shew>Is there anything else though we can really get done here on the common-agenda agenda item #2 though?
15:19<Julian>Thinking...
15:19<shew>I am worrying that we could spend hours and get nowhere here. Or do you think we can actually get some ordered points hammered out?
15:20<Julian>I think we _could_. I don't have the impression that our individual thoughts are that incompatible.
15:20<shew>Okay.
15:21<Julian>willix: Can you try to be back in 20min in _any_ case and tell whether you'll be able to stay or need to go offline entirely?
15:21<shew>Then what are the very top items that should be in the agenda?
15:21<Julian>Yeah, everyone please name your top 3 or 4 priorities from the loose list of tasks on http://new.openspf.org/Project_Agenda .
15:22<Julian>(ordered by priority)
15:23<Julian>I just added "Get SPFv1 published as an RFC." to the loose list as it was missing.
15:23<Julian>(It's probably everyone's #1 anyway, I guess.)
15:25<Julian>My priorities are: 1. Get SPFv1 published as an RFC; 2. Maintain lists of implementation-independent test suites. Bless one of them as an official test suite; 3. Maintain lists of implementations. Bless one of them as an official reference implementation; 4. Get SPF into MTAs proper and into OS distros.
15:27<Julian>(#2 IMO includes _driving_ and _coordinating_ the effort of creating a good test suite, as there is currently none.)
15:27<SDGathman>Mine is same as Julian, except #4 is "maintain list of MTA plugins" (which I just added). There are lots of sendmail-milters to do SPF, but people are always asking about postfix - which also has a plugin API.
15:28<shew>Mine are:
15:28<shew>1. Get spfv1 published
15:28<shew>2. move website to new.openspf.org
15:28<shew>3. directed responses to FUD articles
15:28<shew>4. list (reference) (implementation, test suites)
15:28<shew>5. get spf into MTAs proper and into os distros
15:28<shew>6. campaining domain owners and ESPs/ISPs
15:29<shew>retyping for willix:
15:29<shew>Mine are:
15:29<shew>1. Get spfv1 published
15:29<shew>2. move website to new.openspf.org
15:29<shew>3. directed responses to FUD articles
15:29<shew>4. list (reference) (implementation, test suites)
15:29<shew>5. get spf into MTAs proper and into os distros
15:29<shew>6. campaining domain owners and ESPs/ISPs
15:29<willix>I'm back on another computer. Sorry.
15:30<shew>(I'm not being strict with the catagorization.)
15:30<Julian>willix: Ok. Can you stay or do you need to leave again?
15:30<willix>I should be ok.
15:30<Julian>Great.
15:30<Julian>willix: What are your top priorities from the loose list on http://new.openspf.org/auth/Project_Agenda ?
15:31<willix>please remove "directed responses to FUD articles"
15:31<shew>Julian, SDGathman, can you cut&paste your answers for willix's benefit?
15:31<Julian>My priorities are: 1. Get SPFv1 published as an RFC; 2. Maintain lists of implementation-independent test suites. Bless one of them as an official test suite; 3. Maintain lists of implementations. Bless one of them as an official reference implementation; 4. Get SPF into MTAs proper and into OS distros.
15:31<Julian>(#2 IMO includes _driving_ and _coordinating_ the effort of creating a good test suite, as there is currently none.)
15:32<willix>lets be posive and not negative on official agenda. When FUD article comes in, then we'd discuss it specifically
15:32<shew>willix: Are you suggesting I remove it from my priority list, or that it be removed from the loose-tasks lists?
15:32<Julian>J.d.B.P's FUD article has already come in. I object to removing that from the loose list (it needn't be on the official project agenda).
15:33<willix>from priority list for sure
15:33<shew>(I'm excited at how well the discussion here along with the wiki-updates in real-time are going.)
15:33<SDGathman>Mine (update after seeing Shew's):
15:33<SDGathman>1. publish spf1 RFC
15:33<SDGathman>2. new website
15:33<SDGathman>3. list test suites and bless one
15:33<SDGathman>4. list library implementations, and bless one as reference implementation
15:33<SDGathman>5. list MTA plugins - note which ones are production ready (I don't see a need for such features to be in core MTA code).
15:33<Julian>willix: Can you please tell your top priorities so we can compare our opinions?
15:33<Julian>shew: Heh. :)
15:33<willix>from loose-tasks probably as well, or at least replace with more general "press relations"
15:34<shew>Then I would disagree. I see folks on slashdot and elsewhere often poibnting to that fud article, hence I see a need at a response.
15:34<Julian>Agreed. FUD isn't just a matter of the press. It's a grassroots problem, too.
15:35<willix>Yes and we must deal with it, but not list it as official agenda
15:35<Julian>Official project agenda != loose list of outstanding tasks
15:36<willix>Most companies deal with "fud" by means of "public relations" specialists
15:36<Julian>But let's discuss the official project agenda now. We have priority lists from me, shew, and SDGathman so gar.
15:36<Julian>...so far.
15:37<SDGathman>The Jonathan FUD article has one good point...
15:37<SDGathman>SPF is vulnerable to race conditions during database changes.
15:37<Julian>So are MX RRs.
15:38<SDGathman>A good HOWTO on safely updating SPF without disruption mail is needed.
15:38<shew>Well, we did remove the position that Meng had which included PR responsibilities, concluding that we were all responsible for that. Meaning that "continuing PR" could in a sense be considered one of our ongoing responsibilities and thus not approprite for an agenda item. (Still thinking on that.)
15:38<SDGathman>It can be done - but requires careful preparation.
15:38<willix>Ok from me then - RFC, website, test-suite, relations with MTA and distribution vendors
15:38<Julian>Good, thanks!
15:39<Julian>So let me re-post all the priority lists:
15:39<Julian>Julian: 1. Get SPFv1 published as an RFC; 2. Website; 3. Maintain lists of implementation-independent test suites. Bless one of them as an official test suite; 4. Maintain lists of implementations. Bless one of them as an official reference implementation; 5. Get SPF into MTAs proper and into OS distros.
15:40<Julian>Stuart: 1. publish spf1 RFC; 2. new website; 3. list test suites and bless one; 4. list library implementations, and bless one as reference implementation; 5. list MTA plugins - note which ones are production ready.
15:40<willix>change to "bless one or more as reference implimentation"
15:41<shew>I've taken the liberty of going ahead and putting "Get SPFv1 published as an RFC" as Official-Project-Agenda item #1.
15:41<Julian>Shew: 1. Get spfv1 published; 2. move website to new.openspf.org; 3. directed responses to FUD articles; 4. list (reference) (implementation, test suites); 5. get spf into MTAs proper and into os distros; 6. campaining domain owners and ESPs/ISPs
15:41<shew>Since it doesn't look like there will be any disagreement on item #1. :-)
15:41<willix>5 - list MTA plugins and their use in MTA software - note their conformance to SPF RFC and last update
15:41<Julian>William: 1. RFC, 2. website, 3. test-suite, 4. relations with MTA and distribution vendors
15:41<Julian>--
15:42<Julian>willix: Those are details.
15:42<Julian>Ok, everyone strike "get SPFv1 RFC published" from your lists.
15:43<Julian>I'll repost w/o that one:
15:43<shew>wait...
15:43<Julian>Yeah?
15:43<shew>So "website" is #2 for Julian, myself (shew), Stuart, and William...
15:44<Julian>Ok, let's make that #2. If anyone objects, type "..." fast.
15:44<shew>Would it make sense to make sure we're all clear on what that means, then we can also remove it..
15:44<shew>To me it implies both the updates needed to move it and actually moving it.
15:44<Julian>I think the best we can do is an evolutionary move, until we reach a point where the new website is sufficiently comprehensive that the old website can be archived.
15:45<Julian>That's not to say that we cannot speed up the evolutionary move.
15:46<willix>we could try to decide which pages from old website we will keep and which would not
15:46<Julian>We could, but certainly not right now.
15:47<Julian>Let me try to phrase the project agenda item...
15:48<Julian>"Review and move content from the old to the new website and try to make the new website sufficiently complete that the old site can be archived"
15:48<Julian>Thoughts?
15:48<shew>I had just wrote in "Move new.openspf.org to openspf.org" as a placeholder for the moment, while you were typing that better wording.
15:50<Julian>Alright, any objections to my wording, or can we proceed?
15:50<SDGathman>no objection
15:50<willix>lets go with it
15:50<shew>I'm fine with your wording. However, I would still like to push for an actual date to force the move.
15:50<shew>I'm updating the wiki..
15:51<willix>no actual date please
15:51<shew>with your wording...
15:51<Julian>shew: I see your point, but a hard switch date just won't work.
15:51<willix>decide on pages first on spf-webmasters
15:51<Julian>I mean, of course there will be a hard switch date, but we cannot just define it today. It won't work.
15:51<shew>(I had rather hoped that we could somehow do the rfc announcement on the same day as moving the website over.)
15:52<Julian>willix: Yes, the website move should be discussed on spf-webmasters.
15:52<shew>(I do *NOT* like the idea of having the old website up when zillions of folks come to openspf.org after reading about the official rfc.)
15:52<Julian>I see what you mean.
15:53<Julian>Do you think we could manage to get the new website ready within, say, 2 weeks?
15:53<willix>we could try
15:53<shew>Probably.
15:53<willix>I suspect RFC will come first sometime next week though
15:54<Julian>The RFC won't be published until Wayne is back and has sent our list of list-minute changes and his final OK to the RFC Editor.
15:54<shew>Well, at least we can do sub-bullet items on this page for remaining website work, and that will be clearer to read as the official agenda items are cleared off.
15:54<Julian>But I wouldn't want to artificially postpone the RFC release just because the new website is not ready.
15:55<SDGathman>The new site doesn't have to be perfect. It will have a prominent link to the old site.
15:55<shew>On that note, I'm going to pull off the new top-two agenda items from the loose-collection list..
15:56<Julian>Proposal: Let's meet again when the RFC is about to be published (i.e. Wayne is back and we have submitted our list of last-minute changes) and _then_ define a hard date for the website switch.
15:56<willix>I think that means new website is agenda item #1
15:56<Julian>No, I don't agree. For me the website is secondary to the RFC.
15:57<Julian>It would be nice if the website was ready when the RFC comes out, but it isn't strictly necessary.
15:57<willix>what is item 3?
15:57<shew>Julian: Agree to your proposal. (At least we should revisit the switchover issue.)
15:58<Julian>Shew has "directed responses to FUD articles" as #3, but everyone else has the test suite as #3, and Shew has it as #4. Can we agree to have the test suite as #3 on the project agenda?
15:59<willix>yes
15:59<shew>I request minor discussion.
15:59<Julian>Go ahead.
16:00<shew>Should directed responses really be considered part of our shared responsibility anyway given Meng's PR position responsibilities are now divided among us?
16:00<shew>If that is the case then listing it as an agenda item is almost like listing "attending meetings" as an agenda item.
16:00<Julian>s/directed/focused/ -- When I said "directed" I didn't mean we should send response letters to J.d.B.P & co.
16:01<Julian>...what I meant was that we should write concise counter-articles for the most prominent FUD articles such as J.d.B.P's one.
16:01<shew>I took that as the meaning as well.
16:02<Julian>So that one who has read J.d.B.P's article can come to the SPF website and read the counter-statement.
16:03<shew>Any other comments on my question above?
16:03<shew>(I'm writing an edit for the agenda page, btw.)
16:03<willix>please do so on and direct to spf-council mail list, and we'll try to decide on appropriate anti-FUD actions then. But lets not list it as official items - this is just part of outgoing press and public relations issue that sometimes comes up. Also having it as agenda item #3 gives it too high a role considering its not specific issue like website or RFC or test-suite
16:04<Julian>As I said, I don't think this needs to be part of the official project agenda (it can stay on the loose list of tasks), and I think the council doesn't necessarily have to write anti-FUD itself, it should just try to coordinate the effort.
16:05<shew>Okay. I'll withdraw my suggestion of anti-fud as an official agenda item then.
16:06<Julian>So can we agree to have the test suite as #3 on the project agenda?
16:06<Julian>William and I already agreed, I think.
16:07<shew>Hmm. Re-reading. I had merged them with listing-reference-implementations.
16:08<shew>But I would consider test-suites more important than reference, so yes, I agree.
16:08<Julian>Ok, let's do it.
16:08<shew>Editing it then..
16:08<Julian>Wait a minute.
16:09<Julian>I think that simple listing of "available" test suites and choosing one of them isn't sufficient. The problem is that there is currently no acceptable test suite.
16:10<Julian>I think we need to coordinate and drive the creation of one.
16:10<willix>how many test suites are there?
16:10<Julian>There's a pretty broken one as part of M:S:Q, and there's an also broken one in libspf2.
16:10<shew>Updated the page.
16:11<Julian>Wayne was planning to recover the libspf2 one and overhaul it.
16:11<shew>Then perhaps wording for a sub-bullet item...
16:11<shew>(Everyone might want to reload the page.)
16:11<willix>is M:S:Q using Mail:SPF as library?
16:11<SDGathman>One wrinkle is that any DNS records referenced by the test suite are part of the test suite.
16:11<shew>Wording for an additional sub-bullet item that is.
16:12<Julian>"Maintain lists of implementation-independent test suites" is nice in theory, but in practice it sounds stupid (no offense!).
16:12<shew>That's fine. Having something out there that sounds stupid just helps spur on better wording. :-)
16:12<Julian>willix: No, M:S:Q is not using Mail::SPF.
16:13<willix>And one with libspf2 using the library it comes with?
16:13<SDGathman>I typically run into problems trying to use DNS. Need to load all DNS data into a local database. Test suite ought to include the DNS data as part of the suite, since retrieving all referenced DNS records is non-trivial.
16:13<Julian>"Coordinate and drive the creation of an implementation-independent test suite". We can always bless another one the official test suite if one comes along.
16:13<Julian>SDGathman: I agree that the test suite should work offline.
16:14<shew>Oh!
16:14<Julian>willix: I don't know much about the libspf2 test suite. All I know is that it is incomplete and definitely broken.
16:14<shew>I assummed we were talking about a suite of tests for domain owners to use for testing their record, not a suite of records-and-results for implementation writers to use to test their implementation.
16:15<shew>And the former definitely exists. :-)
16:15<Julian>Heh.
16:15<Julian>shew: No, I guess we all meant the test suite for implementors.
16:16<shew>Ahh. Okay. Well, I was confused, but that doesn't change what my ordering would have been.
16:16<Julian>I think you mean "test tools".
16:16<shew>Thanks.
16:17<shew>So basically we have three similar things to list/bless: Test suites, test tools, and (reference) implementations.
16:17<Julian>Yeah.
16:18<shew>Does everyone think of those three as being grouped together as far as agenda-importance?
16:18<Julian>Although for the tools, I think we should call it "certification", and the the implementations, there should be one reference implementation, and a number of certified implementations.
16:18<Julian>No.
16:18<shew>okay.
16:18<Julian>I think the test suite is a prerequisite for the reference implementation (and for certifying the non-reference implementations).
16:18<willix>I'd rather not even one one reference imlementation if we have multiple certified ones
16:19<shew>Julian: Agreed.
16:19<Julian>Well, a certified one can have new version releases which are not guaranteed to be compliant.
16:19<shew>My meaning of "grouped together" was whether anyone considers that another agenda item would be inserted priority-wise in the midst of those three releated things.
16:20<Julian>(...and I don't think we should require re-certification for every version release.)
16:21<willix>separate url pointing to version that was tested and verified and could be used as a reference (when author of the suite gave permission to list it as such and agreed to maintain this version as separate item)
16:21<willix>maintain - means makes source available as separate item
16:22<Julian>I repeat my proposal for the project agenda: "Coordinate and drive the creation of an implementation-independent test suite". (We can always bless another one the official test suite if one comes along.) Any comments or counter-proposals?
16:22<willix>agreed
16:22<shew>agreed.
16:23<SDGathman>agreed
16:23<shew>willix: (I meant maintaining a list.)
16:23<shew>Let me re-ask my grouping question: Does everyone think of those three as being grouped together as far as agenda-importance?
16:23<SDGathman>Must work offline
16:23<shew>ie, no other agenda items inserted within the three?
16:24<willix>we can add items like reference implimentation and certification later into it when test suite is ready
16:24<willix>lets keep only test-suite for now
16:24<SDGathman>No - once a good test suite is available, officially blessing a reference implementation is not as critical.
16:24<Julian>shew: No, I think that getting SPF into MTAs OS distros is more important than developing test tools. (Merely _listing_ the test tools is trivial, that needn't be on the project agenda, that can stay on the loose lists IMO.)
16:24<SDGathman>Anyone could test an implementation for themselves.
16:25<shew>I've updated the page with Julian's wording.
16:25<SDGathman>Julian: There is nothing worse than handling an SPF-help problem where the receive has a broken implementation.
16:26<willix>MTAs is next item (#4) on agenda, right?
16:26<shew>I would like to change "Get SPF into MTAs proper and into OS distros" to "Get SPF into OS distros"
16:26<Julian>SDGathman: The point of a reference implementation would not just be guaranteed 100% compliance, but also well-laid-out and commented code.
16:27<shew>MTA info should be in another item. Editing the page to write idea there..
16:28<willix>Who decided what code is "well-laid-out" and has "good comments" or not? You know how controversial some of these opinions and decisions can be?
16:29<Julian>willix: That's not the point. I'm sure we'll be able to agree on _something_ for the reference implementation. :)
16:29<SDGathman>We could have ratings, like on movie rental sites, for certified implementations.
16:29<SDGathman>Visitors could rate implementation on clarity.
16:30<willix>Besides that some programmers are better when looking at C code, others want Perl and others something else. We give them list of known implementations that are open-source and 100% compliant and let them choose. If there are not enough comments for some new programmer, he can go back and choose another implementation from our list
16:31<Julian>*sigh* All of that may be right (or not), but that isn't really the point right now.
16:32<shew>I'd sugest a reload of the page.
16:32<shew>Bad wording there on the "was:" versus "suggested", but..I think pushing for OS distribution inclusion shouldn't be confused with pushing for MTA functionality added directly or as a plugin.
16:32<willix>The best we can do is let visitors comment regarding implementation (most wikis I work with make such comments easy - too easy perhaps..)
16:33<Julian>Why do we not want to get SPF into MTAs?
16:33<shew>And IMHO MTA functionality is more important that OS distribution inclusion--the latter will more naturally happen anyway if the former occurs.
16:33<Julian>Exactly.
16:34<willix>We should work with both MTA vendors and OS distribution vendors
16:34<Julian>Oh, I was confused by the web page.
16:34<Julian>Looks about good to me.
16:34<shew>My bad wording again. :-)
16:34<willix>And list both on the item agenda
16:34<SDGathman>Julian - are you talking about plugin availability, or inclusion in core code?
16:35<shew>Then I will remove the "was:" bullet point in the loose-list now. (Any objections?)
16:35<SDGathman>Plugins could be included in MTA source.
16:35<Julian>SDGathman: Doesn't matter. SPF support should be included in MTA distributions (source and binary packages). Whether it is in the core or as plugins is irrelevant.
16:35<Julian>It shouldn't just sit as a patch in a contrib/ folder or something, though.
16:36<Julian>That's what I meant by "into MTAs proper".
16:36<SDGathman>So you want each MTA vendor to bless a particular plugin/patch as the official SPF implementation for that MTA.
16:37<Julian>Yes, no patches though, and it can be multiple plugins.
16:37<SDGathman>I'm not convinced that is necessary.
16:37<willix>If MTA vendor produces this plugin - sure.
16:37<SDGathman>There are many SPF milters for sendmail. All easy to install with standard packages.
16:37<shew>updated page.
16:37<willix>If MTA vendor does not produce the plugin and is unwilling to include 3rd party code, then we work with OS distributions who use that MTA and ask them to include one of the available plugins
16:38<Julian>Define "necessary". It may not be "necessary", but it would be desirable.
16:38<Julian>willix: Exactly.
16:38<SDGathman>I get complaints about postfix not having equivalent SPF plugins.
16:39<Julian>Can we please stop maintaining the loose list of tasks and return to compiling the project agenda (which needn't be all that detailed, just unambiguous)?
16:40<Julian>(Yes, having refined the loose list now is good.)
16:40<shew>Well, if folks agree on the basic meaning of the MTA functionality loose-list, can anyone suggest wording for moving it to the agenda?
16:41<Julian>I'd like us to agree on at least one more item for the project agenda before moving on to the next meeting agenda item.
16:42<shew>(I'd prefer working more on this, as we're filling out the agenda nicely and much more quickly than I had thought possible.)
16:42<shew>I'm going to move the wordy MTA wording to the agenda..
16:42<Julian>Just _copy_ it for now.
16:43<Julian>Oh, stop.
16:43<Julian>Let me rehash what everyone has for #4 and #5 on their priority lists:
16:43<Julian>Julian: 4. Maintain lists of implementations. Bless one of them as an official reference implementation; 5. Get SPF into MTAs proper and into OS distros.
16:43<Julian>Stuart: 4. list library implementations, and bless one as reference implementation; 5. list MTA plugins - note which ones are production ready.
16:43<Julian>Shew: 4. get spf into MTAs proper and into os distros; 5. campaining domain owners and ESPs/ISPs
16:43<Julian>William: 4. relations with MTA and distribution vendors
16:43<Julian>--
16:45<Julian>So Stuart and I think that the library implementations and reference implementation should come first, and Shew and William think that that isn't necessary and that we should go on to getting SPF into MTAs/OS distros immediately.
16:45<willix>Agenda item 4: "Coordinate with MTA and OS vendors to support SPF in base distribution"
16:46<shew>I wanted MTA support first.
16:46<shew>Rather I consider it more important.
16:46<shew>oh. Sorry.
16:47<shew>Edit question: Any objections to my going ahead and moving the MTA thing into the agenda for the moment?
16:47<willix>agenda items order does not mean one entirely depends on another
16:47<shew>Just for ease of editing and seeing-the-same page.
16:47<Julian>willix: True.
16:48<Julian>shew: Yes, objection raised.
16:48<shew>The edit is merely that I already had it in my buffer, and we can easily add another item in front.
16:48<shew>This is for ease-of-edit reasons only.
16:49<Julian>Well, if that's the case, then why are you asking? :)
16:49<shew>Okay. :-)
16:49<Julian>May I propose the following compromise: 4. Complete the list of library implementations, determine their states, and determine if one of them can be blessed as reference implementation immediately; 5. Coordinate with MTA and OS vendors to support SPF in base distribution.
16:49<Julian>That #4 should be doable in very little time.
16:49<Julian>And, as William said, it wouldn't mean that #5 cannot be started before #4 is completed.
16:51<shew>Re: compromise: I don't think there has really been a disagreement.
16:52<shew>I'm more trying to clear up on what folks are meaning. I haven't found any reason to disagree yet. :-)
16:53<shew>I just moved the implementation, MTA support, and OS vendor items as temporary-edit items into the agenda with the old wording.
16:53<shew>(As preface to the debate on new wording and actual ordering.)
16:53<shew>So a page reload should give old-wording items with the ordering that I think is going on in folks minds..
16:53<Julian>I already proposed a wording for #4 in my compromise.
16:54<willix>shew - your last update with items 4 and 5 is probably too verbose
16:54<Julian>Agreed, a bit too verbose for the project agenda.
16:54<shew>Julian: What is the compromise compromising between?
16:55<SDGathman>Note about MTA support. Only the SPF result can be standardized. Policy decisions based on the SPF result must be customizable. And it must be easy to provide extended results - e.g. guessed SPF record for None or auto-DWIM for PermError.
16:55<Julian>16:45 UTC <Julian> So Stuart and I think that the library implementations and reference implementation should come first, and Shew and William think that that isn't necessary and that we should go on to getting SPF into MTAs/OS distros immediately.
16:55<shew>willix, julian: This was merely to move from the loose-list to the agenda for the moment. I absolutely would want rewording to something similar. Don't consider this as suggested wording.
16:55<shew>Julian: I disagree with your summary of viewpoints.
16:55<shew>In the sense that I agree with you and Stuart. :-)
16:56<Julian>Well, that's what I read from everyone's priority list.
16:56<Julian>Never mind.
16:56<Julian>SDGathman: Probably true, but those are details.
16:56<shew>So I take it that Julian, Stuart, and I agree on the ordering of (implementation, MTA support, OS distribution) then..
16:57<Julian>Yes, I agree.
16:57<shew>willix: Do you suggest a different ordering?
16:57<Julian>(shew: Can I edit the page for a minute?)
16:57<willix>I'm fine with ordering, but prefer #5 & 6 together and without separate subitems
16:58<shew>(julian: Sure. In fact I was just trying to word things in my mind about how to ask if I were being offensive with too-many-edits.)
16:58<shew>willix: Cool.
16:58<Julian>(shew: then please save your current edits and tell me when I can edit.)
16:58<shew>No I'm done.
16:58<shew>edit away.
16:58<Julian>k, editing.
16:59<shew>So we're all fine with the same ordering, and it's just an edit question then. And julian already has better wording he suggested above that I'm guessing he's wordsmithing into something even better. :-)
17:02<willix>Julian - while you're at it, please remove the word "FUD" from loose list and replace with either just "addressing critisicsm" or more general "public relations and press contacts"
17:02<Julian>Perhaps "unfounded criticism" (AKA FUD)?
17:02<SDGathman>The JBP article qualifies as FUD. I could only find one valid point (and that is easily addressed).
17:03<Julian>I absolutely concur with SDGathman.
17:03<willix>There is a difference in how you call things on public website and your own personal blog
17:04<Julian>Sure, so what?
17:04<Julian>We don't have to be politically correct. We just have to be correct.,
17:04<willix>There is also no need to actually point to Pollard's article from our page :)
17:05<shew>In a todo type list I have no problem with the term "FUD". In a response, IMHO "FUD" would not be appropriate.
17:05<Julian>Why not point there? If our arguments are better, there is no harm in pointing to his article.
17:05<willix>Then point to our response to that article as well
17:06<Julian>We have none (yet). I see your point.
17:06<Julian>Anyway...
17:06<Julian>Please reload http://new.openspf.org/Project_Agenda and see if this is acceptable.
17:06<SDGathman>But the link to the FUD is necessary for someone to start compiling responses.
17:07<Julian>I have moved the detailed items (which are good, just too verbose) back to the loose list.
17:07<willix>that is why we should be less specific when website is made public face of SPF
17:07<Julian>Guys, the old website is far more embarrassing than a link to J.d.B.P's article.
17:07<shew>I still think the MTA and OS support should be separate items.
17:08<Julian>shew: From an operational/organizational POV, please explain why.
17:08<shew>(I agree with embarassment.)
17:10<shew>I'm just thinking of the logistics of someone talking with an OS distributor about setting up SPF functionality as easily configurable in their default installs. To me that's just a separate sort of thing than pushing for MTA functionality. The former is more political, and the latter is more of looking for developer interest.
17:10<shew>I realize I'm not exactly answering your question in the way you ask it.
17:11<shew>Telling a distributor: Here are the tools that exist to do thus-and-such, versus talking on an MTA-related mailing list of "Are there any developers interested in writing thus-and-such?" seem..different to me.
17:11<Julian>The real question, I think, is whether a separation of those two items in the project agenda makes a difference in everyone's (council+community) understanding of what we're trying to achieve and what must be done, and whether further discussion on whether they should be separated is worth another 15min.
17:12<SDGathman>Also, as an admin for 40 systems, it is no problem when there is a functional RPM for a plugin that I can click, download and install. Distro support is nice, but not required.
17:13<Julian>I don't really care (that makes one abstention out of 4). If two people agree they should be separated, then let's separate them and be done with it.
17:13<shew>I think it does make a difference.
17:13<Julian>shew, SDGathman: Separate or not?
17:13<shew>For one, I would put the campaigning thing above the OS support.
17:14<SDGathman>Separate
17:14<Julian>I could live with that.
17:14<willix>I would prefer no separation
17:14<shew>Since ISPs can easily support spf before any recalculant distributions
17:14<Julian>That makes 1 abstention, 2 for separation, 1 against. Thank you. :-)
17:15<shew>Things like this are why we voted for you for fearless-leader. :-)
17:15<Julian>Please reload. Acceptable?
17:15<shew>Fine with me.
17:15<willix>ok
17:15<Julian>(Modulo the campagning issue)
17:16<shew>Any objections to removing the needlessly-more-verbose copies from the loose-list?
17:16<SDGathman>We got concensus on the first 4 priorities. We are arguing over number 5 and/or 6. Pretty good, I'd say.
17:16<Julian>So, should we add/insert the campaign item to the project agenda, too?
17:16<Julian>If yes, where?
17:16<Julian>I'd be ok with "between 5 and 6" or "after 6".
17:17<shew>I prefer between, but after-6 is also okay as a second choice.
17:17<Julian>shew: I wouldn't say they're needlessly verbose. They contain valuable details, such as the postfix/qmail status, etc.
17:18<shew>Well the library implementations...that one can be deleted...
17:18<Julian>No.
17:18<willix>in the loose items instead add something from what SDGathman said above, i.e. consider table or database to help users find or download SPF supporting package for their particular MTA and OS distribution
17:19<Julian>#4 in the project agenda is only suited as an immediate goal, not as a long-term task.
17:19<shew>Oh. Okay.
17:19<shew>Then we can clean that part up later.
17:20<Julian>Yeah.
17:20<shew>I'll clean up while the campaign item is being discussed.
17:20<Julian>Remember that we can always modify the project agenda later if there is consensus. So, any objections to having "Start a grassroots 'Spread SPF!' campaign to get in touch with domain owners and ESPs/ISPs" as #6 (before the current #6) in the project agenda?
17:21<shew>No objectiosn. It has my vote.
17:21<willix>prefix this with "SPF Advocacy and start of new "
17:22<shew>No objections that is.
17:22<shew>I'm fine with willix's rewording or any other discussion of rewording. (And feel free to update the page btw.)
17:22<Julian>willix: What kind of concrete advocacy do you have in mind?
17:23<shew>Oh. I take that back. I'm fine with "Start of new", but the advocacy bit sounds nebulous.
17:23<Julian>(I mean, I'm sure we're all advocating SPF at each and every possibility, right? ;-) )
17:23<willix>Like project website this is general item that is part of the agenda
17:23<SDGathman>Every spam with forged MFROM I get sends an SPF pitch.
17:23<willix>then we go into more specific
17:24<SDGathman>Well, modulo caching to do it only once a month.
17:24<Julian>willix: True, but people need to understand what is meant by "SPF Advocacy".
17:24<Julian>So please explain what you mean by that.
17:25<willix>I don't think they need to.
17:25<Julian>Look guys, I have been up for 7 hours and haven't even had breakfast yet...
17:25<willix>And what I do means is basicly spreading the word to our peers and on email security and related events
17:26<shew>Then that shouldn't be there as it doesn't fit in with the rest of that item.
17:26<willix>Ok, lets rep it up then.
17:26<willix>I'm rather sleepy myself actually
17:26<shew>I also don't think it should really be a specific agenda item at all. (General advocacy.)
17:26<Julian>No, we have the announcements item on the meeting agenda, and I _really_ really would like to handle that.
17:27<willix>Can you send a draft to spf-council list then?
17:27<Julian>Draft of what?
17:27<Julian>We're not done with the project agenda just yet.
17:28<Julian>Please let's finish that first, but quickly.
17:28<shew>ordering and wording are two separate items. Can we discuss ordering first and quickly?
17:28<shew>I vote for between-5-and-6, but I'd take after-6 as a second choice.
17:28<willix>Lets leave agenda as is and pick it up on one of the next meetings
17:28<Julian>I think no one objected to inserting the campaigning item between 5 and 6.
17:29<shew>Please no--we can finish this quickly I think.
17:29<Julian>Agreed. Please. We're almost there!
17:29<shew>We're almost completely done. I am fine with Julian's wording...
17:29<shew>Or the prepending of "start of new"
17:29<willix>I mean that we can decide if campaign needs to be brought up into official agenda after RFC publication
17:29<shew>Since there were no objections, can you reload and insert?
17:29<shew>julian?
17:30<Julian>willix: Do you object to having the campaign in the project agenda (generally or at this time)? No problem if you object, but please tell.
17:30<shew>(I deleted the one-line os-support from the loose-list.)
17:30<willix>I think this is premature for right now
17:31<Julian>willix: What do you think would have to change for it to be no longer premature, and why?
17:31<Julian>(Just trying to understand.)
17:31<willix>website, RFC and other issues really need to be done first
17:31<SDGathman>After #5, priorities are rather twiddly, and I have no strong feelings about exact order.
17:32<shew>To do two-things-at-once: Should the "Working on or brainstorming on the design of a newer version of SPF" item be put in as the very last, lowest-priority agenda item?
17:32<Julian>willix: Of course the other things need to be done first. That's why they are listed higher in the priorities list. :-)
17:32<shew>Agree re: priorities list. :-)
17:32<willix>then when we're closer to being ready we revisit and start campaign and right now general advocacy
17:33<SDGathman>I'd say new website is a prerequisite for any new advocacy campaign.
17:33<willix>Yes, but I think in case of serious campagn we really do need those other items done first and be almost complete
17:33<Julian>Well, ok, if you really think we should not add the "campaign" and "SPF++" items to the project agenda, I could live with that.
17:33<shew>One suggestion..
17:33<Julian>I don't really understand why not, but I could live with it.
17:34<shew>Perhaps a Future/Secondary Agenda: ("Things to do after the above are mostly done, that are mostly blocked by the Primary Agenda".)"
17:34<shew>Or,
17:34<SDGathman>I'm fine with adding campaign and SPF++ as last items.
17:34<shew>these two items could be listed in the agenda with something prepended to each one: "After items 1-6 are mostly done: blah"
17:35<Julian>Oh, personally I wouldn't even add the SPF++ item myself right now. It really hasn't been decided if another SPF version is worthwhile.
17:37<shew>Hmm..
17:37<Julian>So, let's not add SPF++ right now. About the campaign: I would like to add it, and shew and Stuart have no objections, but William does. I wouldn't like to vote on that by majority vote. (We don't even know what Mark K. thinks...) So let's not add the campaign right now either.
17:37<shew>I have a notion on the campaign..
17:37<Julian>We can always change the project agenda later.
17:37<SDGathman>Once spf1 is widely adopted, spf2.1 could finally dispense with TXT records.
17:37<willix>ok I thought about it more and I withdraw objection to moving SPF campaign as last item. Its good to have for public view
17:37<Julian>shew: Yes?
17:37<Julian>LOL
17:38<Julian>Anyway, we can always change the project agenda later, so no harm is done by deciding one way or another now.
17:38<shew>Campaigning ISPs/ESPs doesn't mean trying to push SPF on them over their objections, but pointing out why we think it's a good idea, getting their feedback, and finding out why they aren't using it now.
17:38<Julian>shew: Agreed.
17:38<shew>Asking questions is part of campaigning, and doesn't require everything to be in order first.
17:39<Julian>So please reload http://new.openspf.org/Project_Agenda and tell your comments and/or objections.
17:39<shew>So I think it is good for, as willix just said, the public view thing if nothing else, and it's something we can do at a lower-priority while getting everything else together.
17:40<shew>Good.
17:40<shew>I have wording comments though.
17:41<shew>But fine with it being there--I withdraw my preference for between-5-and-6. I like it after 6 now that I think of it.
17:41<shew>Thinking on the 'grassroots "Spread SPF!"' text.
17:42<shew>that's all. Probably not important enough to spend time on at the moment., and if other names come up we can change that later.
17:42<Julian>This is not meant as a predetermination of details (whether it is 100% grassroots, or whether "Spread SPF!" should really be the motto).
17:43<Julian>It's meant to bring across the general idea.
17:43<Julian>So, SDGathman, willix, any comments or objections?
17:43<shew>I quite understand.
17:44<willix>possibly removing "grassroots" from line you mean?
17:45<shew>I was thinking removing 'Start a grassroots "Spread SPF!" ' altogether.
17:45<shew>This is a minor edit thing though really.
17:45<Julian>willix: Well, the grassroots element is a main point of the idea, because we have little other resources. We can go to conferences and talk to ISPs/ESPs, but that's about it.
17:45<shew>It just took me some time to think through everything in my head.
17:46<shew>Well, doing any real effort will require coordinating talking with ISP/ESPs, so we don't deluge folks from all over.
17:46<willix>In my view this line is right now primarily for publicity and it sounds good as is
17:46<shew>ie, listing them out, different folks talking with different ones, reporting back, etc. That's a non-grassroots kind of thing.
17:47<willix>when we're done and have concrete ideas for this campaign, then we can rephrase it
17:47<shew>Okay. Not worth debating those details now then.
17:48<Julian>shew: I agree that non-grassroots elements are probably worthwhile, but I fear we won't have the man power to make that the main focus.
17:48<shew>Okay.
17:48<Julian>Ok, so do I see any further objections?
17:48<Julian>SDGathman?
17:48<shew>No objections here.
17:49<SDGathman>No objections.
17:49<Julian>Consensus! Awesome! (Although I'm sure that Mark K. would have preferred the campaign as priority 1 and the test suite as priority 7...*eg*)
17:49<Julian>(just joking)
17:49<SDGathman>(Just had a brainstorm about need for standard way of reporting "debugging" reedback for SOFTFAIL result.)
17:50<shew>heh.
17:50<Julian>So, let's move on to the next regular item on the meeting agenda:
17:50<shew>Minor sanity check:
17:50<shew>Any objections to me changing:
17:50<shew>The following items and tasks have not (yet) been put on the official project agenda but need to be addressed nonetheless. If you have write access to this page, feel free to add items to this list.
17:50<shew>to:
17:50<shew>If you have write access to this page, feel free to add to or edit items on the following list.
17:50<shew>?
17:50<shew>(Since there is now some overlap.)
17:50<shew>Just a sanity check.
17:50<Julian>I have no objection to that.
17:50<willix>go
17:50<shew>ok
17:51<Julian>So, let's move on to the next regular item on the meeting agenda:
17:51<Julian>4. Announcements (to spf-announce/as a press release)
17:51<willix>I think there needs to be 2 press-releases
17:51<Julian>a. the election of the new council and its common agenda,
17:51<Julian>b. the SPF project's comments on the outcome of the IESG/IAB appeals,
17:51<Julian>c. publication of the SPF RFC,
17:51<Julian>d. other noteworthy news.
17:51<Julian>--
17:51<willix>One for appeals and RFC publication
17:52<Julian>announcement != press release
17:52<Julian>We can send news to spf-announce without having it as a press release.
17:52<willix>and another one regarding council and general agenda if we can come up with how to properly phrase it
17:52<Julian>And I think we should send out interesting news to spf-announce more often than we have done in the past year.
17:53<willix>Yes good point. Announcement need not be as verbose probably
17:53<Julian>I think we should have a PR about the RFC (and possibly about the failed appeals), but not about the new council or its agenda.
17:54<Julian>Only an informal spf-announce message about the latter.
17:54<shew>Agreed on informal spf-annonce message.
17:54<willix>council and agenda as announcement and RFC and appeals as PR + announcements