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/02/05_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

--- Sun Feb 5 00:00:57 UTC 2006 ---
00:00<willix_>I know for sure some IETF senior members discussed it, I don't know if it included entire IAB/IESG or not
00:02<Julian>I said the following on spf-discuss:
00:02<Julian>The IAB cannot modify IESG decisions or make their own decisions, all they can do is _undo_ IESG decisions. Since we have _not_ appealed to the IESG about their decision not to publish draft-schlitt-spf-classic as a "Proposed Standard", appealing to the IAB cannot turn draft-schlitt-spf-classic into a "Proposed Standard". All an appeal to the IAB can achieve is to stop the Sender-ID spec from being published as-is as an "Experimental RFC".
00:02<willix_>Another issue is that what'd need to appeal is failure to follow IETF procedures. I looked hard and could not find exact procedures for experimental publications in the sam way these guidence are given for standard documents
00:03<Julian>No, appeals to the IAB can be of technical nature, too, not just procedural.
00:04<shew>Julian: My understanding of the appeal we were discussing/proposing was to appeal to the IAB to stop the Sender-ID spec from being published with this incompatibility.
00:04<Julian>Correct.
00:04<Julian>I'm not so sure however that the IAB considers a conflict in _Experimental_ RFCs a serious problem. We're not standards track, after all.
00:06<Julian>Anyway, does anyone want to make a motion? Or is more discussion required?
00:06<Julian>(T = +126min)
00:06<shew>Hmm. What would be the practical impact of the IAB not considering such conflicts serious? (Are you suggesting that this might mean a longer delay?)
00:07<Julian>It could mean a longer delay, or it could mean that the IAB doesn't want to revert an IESG decision of such a small (perceived) consequence.
00:08<willix_>Its not a motion, but I'm thinking that even with no appeal a response is necessary. What I'm thinking of is writing a letter (but not an appeal) to be posted on IETF main mail list explaning that we believe IESG made incorrect decisions but in the interest of expedeincy and so as not to delay RFC publication we would launch an appeal to IAB eventhough it was appropriate
00:08<Julian>(I'm merely speculating, though.)
00:08<SDGathman>Even if the IAB *did* stop the publication of a conflicting SenderID, would that stop the MS world from proclaiming loudly that people "should publish SPF1 if their MFROM and PRA are identical"?
00:08<Julian>Of course we think that the IESG's decision is wrong, otherwise we wouldn't have filed the appeal in the first place. ;-)
00:09<Julian>(But I wouldn't be against someone writing such a letter.)
00:09<shew>Well, people *should* publish spf1 if their mfrom and pra are identical. :-)
00:09<Julian>SDGathman: Hard to say.
00:09<willix_>Yes, but I mean that response made by IESG due to appeal about adding additional text was not enough to releieve the issue
00:09<shew>and happen to be identical to spfv1's syntax of course. :-)
00:10<shew>Okay, I imagine that even if we vote to no-appeal, that we'll probably want to write that sort of email. (That's a good idea, willix_)
00:10<SDGathman>shew, I meant "only if"
00:11<Julian>BTW, I think MS doesn't really care about the RFC 2821 identities.
00:12<SDGathman>I agree.
00:12<MarkK>julian: agreed; they're in the header business
00:12<SDGathman>I spoke with a friend who works for Microsoft.
00:13<shew>SDGathman: Okay. Well, MS will always have marketing power to spread confusion, whereas we can merely be honest.
00:13<SDGathman>We argued about the SPF reuse problem. His defence was that perhaps it was a technical mistake, and not deliberate sabotage.
00:13<Julian>I can't believe that. MS is many things, but they're not stupid.
00:14<Julian>On the other hand, there was this "XML in DNS" thing, so maybe the _are_ stupid.
00:14<willix_>It was not a confusion, MS people know exactly what they were doing
00:15<shew>I don't think it's right to not object when we have a wider, less-tainted audience to object to.
00:15<willix_>I'm also pretty sure based on some passing remarks by several key individuals that reuse of spf records was one of the agreed points when Meng first discussed it with MS in spring 2004
00:15<Julian>shew: You mean it is our responsibility to escalate the appeal?
00:15<MarkK>yeah, the XML in DNS thing was kinda silly
00:16<willix_>At that time they were talking about supporting both v=spf1 and new XML syntax of course
00:16<Julian>It was silly none the less.
00:16<MarkK>but not stupid: it was just a means for them to gain control over DNS
00:16<shew>Julian: A qualified yes. The only thing that keeps me from being super gung-ho on that responsibility point is the wording of the addendums made to both standards, that implies that sender-ID couldn't get non-experimental draft-standard with its existing problems.
00:18<willix_>XML for policy records is not stupid. Its another issue that DNS has space resrictions which makes XML not a very good choice.
00:18<shew>Julian: Sort of a diplomatic way of saying this-document-will-have-to-be-fixed-to-get-further. I wasn't sure of that interpretation, but given the possibile implication that the sender-ID document would die in experimental status, that lessons the "responsibility" argument slightly. (Hence "qualified yes".)
00:18<Julian>There's another issue. We won't be able to submit a "SPFv2.1/v3" document that merely refers to draft-schlitt-spf-classic for standards track if the latter is not standards track. We would have to include all of the text of draft-schlitt-spf-classic in a new document and resubmit it.
00:19<Julian>willix_: XML is a waste of processing resources for a thing as lightweight as SMTP.
00:19<Julian>(yeah, the lightweightness of SMTP is relative)
00:20<shew>Julian: Good point, and I hadn't thought of that, but IMHO it shouldn't have any bearing on this decision.
00:20<Julian>Probably true.
00:20<Julian>So, what are we going to do?
00:20<willix_>I think it would be better for us to focus on positive aspects of SPF as being core protocol for security SMTP session identities
00:21<willix_>We then provide new drafts on this point for future protocol version completely bypassing PRA & SID (which would have to battle against DKIM and good luck to them on that point).
00:21<shew>Let's get a poll.
00:22<Julian>I said I would abstain from the vote on the IAB appeal.
00:22<shew>My yes-appeal intention is still strong, and I don't see discussion that dissuades me. However, if there are new points or other rewording of points, I am open to listening to them, and I'm open to a short delay if there's consensus to ask spf-discuss about it again and have an 11th-hour meeting.
00:23<SDGathman>I don't think a successfull IAB appeal will stop the MS FUD.
00:23<Julian>I don't think any new points are going to come up.
00:23<willix_>I'll also be abstaining.
00:24<shew>Nothing will stop MS FUD either way. But we can help steer what's a standard and what isn't.
00:24<MarkK>We could bounce it to discuss. Or, we could talk more.
00:25<willix_>shew: I was willing to vote yes if there was strong showing that was on spf-discuss and clear consensus. I'm not against asking for it again and holding emergency vote on spf-council
00:25<Julian>SDGathman: A successful IAB appeal might not stop the MS FUD, but it might shut up detractors like Doug Otis.
00:26<Julian>Or it might not.
00:26<MarkK>Somehow, I do not think Doug Otis is likely to ever shut up. :)
00:26<Julian>Well, in my perception there is a _rough_ consensus on spf-discuss to escalate the appeal.
00:28<shew>Okay, so the question people are mulling over is whether to vote now or ask spf-discuss again, right?
00:28<MarkK>time is running out real fast, though
00:29<willix_>I did not see "rough consensus"... But I think we should vote right now to see of 3 votes are there or not right now.
00:29<Julian>If the council votes to escalate my appeal, I'll have to edit the appeal so it can be presented to the IAB. This would require about a day, I think.
00:29<willix_>If not we can then go for another motion to poll spf-discuss on this issue again
00:30<shew>For a vote right now I'd vote for the appeal.
00:30<Julian>Someone make a motion?
00:30<shew>with willix and Julian abstaining I think..
00:30<shew>No need for motion at this point I think--if the other two folks are more interested in asking spf-discuss and are on-the-fence, we don't need an official motion yet I wouldn't think..
00:30<MarkK>and me likely opposing or doing the same. :)
00:31<shew>So Stewart..?
00:31<shew>Stuart.
00:31<Julian>Ugh, we can't have 3 or more of us abstaining. That'd be silly.
00:32<MarkK>for the record, I do not intend to be the one to block it, when it comes down to it; It's just that I really do not see the gain
00:32<SDGathman>I'd probably abstain.
00:32<SDGathman>Politics is not my forte.
00:32<shew>Okay, we have an awkward situation.
00:32<Julian>Let's ask the reverse question: what harm could the IAB appeal do to us?
00:33<SDGathman>I keep going back and forth, as far as the points presented.
00:33<SDGathman>The harm woiuld be to delay the RFC.
00:33<Julian>The IAB could in theory annul the IESG's decision to publish both SPF and S-ID as Experimental RFCs. Then we'd have no RFC at all.
00:33<MarkK>It could cause such a delay that ppl will start passing up on SPF altogether
00:33<SDGathman>The benefit if successful would be to stop the conflicting SenderID appeal.
00:34<SDGathman>MS FUD will continue in either case.
00:34<MarkK>SDGathman: yes, *only* if successful; so, is that a realistic expectation?
00:35<willix_>As somebody noted people in email industry are also very unhappy and think SPF is hard to work with. We need to show them that we can move forward and not just pick on each point
00:35<shew>An additional delay is the harm that comes to mind, variability in the delay being the big thing. I am not as worried about the IESG anulling both rfc's as being an actual threat to be concerned with.
00:35<Julian>We can decide to decide nothing, and the deadline will pass, so we will have decided not to escalate the appeal. ;-)
00:36<MarkK>william: fully agreed
00:37<shew>As far as the email industry, there is no reason to change how you interpret spfv1 records in spf context because of these political issues. I don't think anyone is truly worried that the ietf will change how spf-interpreted spfv1 records must be interpreted.
00:37<Julian>Ok, guys, we're not getting anywhere. If someone wants to make a motion, do it within the next 3 minutes, or we'll move on.
00:37<willix_>We need decision anyway. We can ask SPF Community for stronger showing and more people commenting on this issue and present a choice of providing an appeal or just doing official response on IETF list as I proposed
00:37<Julian>We could ask our advisory fellows to speak up.
00:38<SDGathman>Motion: ask spf-discuss for more debate. Schedule another spf-council meeting for a vote before the deadline
00:38<Julian>I can tell you what they'd say.
00:38<Julian>When exactly is the deadline?
00:38<willix_>Wednesday is last day to file an appeal
00:39<Julian>0038u: seconded.
00:39<Julian>Votes?
00:39<shew>draft Motion: The council will again ask for the spf community's opinions on the IAB appeal (of the sender-ID (experimental) draft, and will hold an emergency meeting shortly thereafter to decide how to proceed. The community menbers will be requested to give another (stronger)showing of for/against as well as how much each person is behind their decision.
00:39<shew>I rescend my draft.
00:39<shew>rescind.
00:40<shew>0038u: Yes.
00:40<willix_>0038u: yes
00:40<Julian>0038u: yes
00:40<SDGathman>00:30u: yes
00:40<Julian>MarkK?
00:40<SDGathman>Suggest Tue 13:00 UTC or later for emergency meeting. Does that leave enough time to draft appeal?
00:40<MarkK>0030u: yes
00:41<MarkK>0038u: yes
00:41<Julian>SDGathman: I guess it would.
00:41<MarkK>(sorry)
00:41<Julian>Unanimously ordered.
00:41<shew>Motion: Table agenda items #4 and #5 until our next meeting.
00:42<Julian>0041u: seconded
00:42<SDGathman>0041u: yes
00:42<Julian>0041u: yes
00:42<shew>0041u: yes
00:42<willix_>0041u: yes
00:43<MarkK>0041u: yes
00:43<Julian>So the meeting is hereby adjourned. William, would you take on the task of writing the mail to spf-discuss?
00:44<willix_>I'll try. I'd be good if I had entire copy of the meeting log though
00:44<willix_>(I did not keep the log after my reconnect)
00:44<shew>(Technically we should vote on adjournment. Not an issue for now but I'd request it in the future.)
00:44<shew>(I can email.)
00:45<willix_>Ok
00:45<Julian>willix_: The log should show up in http://www.schlitt.net/spf/spf-council/2006/02/ soon
00:45<Julian>shew: Ok, will do. Are you going to sent William the chat log?
00:45<shew>Oh. Then never mind. :-)
00:46<Julian>Well, it could take up to 22h for the log to show up in that dir.
00:46<Julian>The 2006-02-04 log has shown up 1h46min ago, but the 2006-02-05 log might take until tomorrow.
00:47<willix_>shew: email me the logs anyway if not difficult
00:47<shew>Hmm. I just realized I'm not familiar with x-chat logging and cut&paste doesn't pull timestamps.
00:47<shew>Looking at logging..
00:47<Julian>I can send the log, mine has timestamps.
00:47<shew>I've got it enabled but I've never actually used it.
00:47<shew>That would be good, as it will take me a few minutes to figure it out.
00:47<Julian>Ok, I'll send it to William.
00:48<shew>Thanks.
00:48<willix_>thank you Julian
00:48<shew>Yes, thank you!
00:48<shew>And thank you, MarkK, for being the active Chair before Julian.
00:49<Julian>(Unfortunately, my timestamps are UTC+01, not UTC... but I'm sure William will figure it out.)
00:49<Julian>BTW, is our next meeting on Tuesday supposed to be a full meeting or just an emergency one to decide the appeal issue?
00:50<MarkK>I think the latter
00:50<willix_>I'd prefer emergency and then another meeting next satarday if people can make it (if not then two weeks from now).
00:50<Julian>Ok.
00:50<SDGathman>agreed
00:51<shew>agreed
00:55<Julian>Chat log sent.
00:59<shew>Well, good meeting everyone. Hopefully the next one will be much shorter. :-)
01:00<Julian>Agreed.
01:09<willix_>Ok, I got the logs. Thanks.
01:15<Julian>willix_: Remember, feel free to keep the minutes a lot tighter than I did in the past.
01:16<willix_>I'll work on post to spf-discuss requesting additional discussions and summarizing some of the points for and against the appeal. This can be ready in about 2-3 hours as I want to eat first...
01:17<Julian>No worries.
01:17<Julian>I'll go to bed now, it's 02:17 AM over here.
01:17<Julian>Night!
01:19<willix_>The actual meeting minutes will come later as separate email to spf-council..
01:19<willix_>bye all
01:19<willix_>\q

This report was generated at Sun Feb 5 02:41:31 UTC 2006.