[10:11:00] --- ggm has joined
[10:11:46] --- warlord has joined
[10:11:48] --- andy has joined
[10:11:52] --- mrose has joined
[10:19:00] --- mengwong has joined
[10:19:06] <mengwong> moo.
[10:19:10] <mengwong> what room are we meeting in?
[10:19:23] <mrose> grande A
[10:19:48] <wrs1864> there was a message on the MARID list saying that the room would be moved so that the multicast video would be available
[10:20:16] <wrs1864> Listening to Ch 2 audio, however, it sounds like the room hasn't been moved.
[10:21:13] <wrs1864> Woah, cool music on Ch 2
[10:21:32] <mrose> then you have the right room
[10:24:14] --- galvinjamesm has joined
[10:24:44] <mengwong> hey.
[10:25:00] <galvinjamesm> hey hey, love the audio!
[10:25:10] <galvinjamesm> Whose music is that?
[10:25:16] --- mtnviewmark has joined
[10:25:40] <mtnviewmark> mu
[10:25:41] <wrs1864> Yeah, I think Marshall is playing it so that we can't listen to what they are talking about before the meeting...
[10:26:25] <wrs1864> oh, that should have a ;-)
[10:26:25] <galvinjamesm> Oh, but I can hear Marshall quite clearly.
[10:26:28] <galvinjamesm> Oh but I can hear Marshall quite clearly. Hi Marshall!
[10:27:36] <mrose> hola
[10:27:57] --- hadmut has joined
[10:27:58] <galvinjamesm> No fair, speak hello.
[10:28:15] <hadmut> Good morning everybody
[10:28:50] --- DouglasOtis has joined
[10:28:57] <ggm> do we have a scribe? I don't mind if nobody else is..
[10:29:38] <mrose> ggm - you're elected.
[10:29:48] <mrose> how many people in the room have subethaedit?
[10:29:55] <galvinjamesm> Yes, thanks, as always, to the scribe!
[10:30:09] <ggm> um. I don't have subethaedit. should I?
[10:30:17] <mengwong> for os x.
[10:30:31] <ggm> oh. NetBSD. ok. back to sleep then :-)
[10:30:32] <mengwong> http://www.ietf.org/ietf/04aug/marid.txt
[10:30:36] <mengwong> ahem.
[10:30:39] <mengwong> http://www.codingmonkeys.de/subethaedit/
[10:31:07] <mrose> sorry, yes mac os x. i hear that subethaedit is all the rage for multiple people doing meeting minutes. one person does most of the heavy lifting and others follow along making corrections, edits, annotations, etc.
[10:31:23] <mrose> just asking, let's not do it here (unless some folks have done it before)
[10:31:36] <ggm> nice! like the UCL shrimp shared text editor but done in a decent GUI!
[10:32:20] <mrose> yes. apparently it's built on the "million monkeys" framework. for that reason alone, we should be using it.
[10:32:26] <mtnviewmark> yes -- many of us have done it before
[10:33:05] --- mtnviewmark has left: Disconnected
[10:34:07] --- gconnor has joined
[10:34:14] --- hardie has joined
[10:34:39] --- hadmut has left: Disconnected
[10:34:52] --- hadmut has joined
[10:36:03] <wrs1864> Thanks for being the scribe ggm!
[10:36:19] --- pawal has joined
[10:36:26] <wrs1864> Is Dave Crocker going to do the channeling for us this time too?
[10:36:52] <ggm> Hmm. GAIM lets me force bold on. If I do this, it might help make scribe text show up against the dialogue. is it too ugly?
[10:37:02] --- peterd has joined
[10:37:08] <DouglasOtis> Where the channel meets the From...
[10:37:12] <gconnor> I can't see any difference on my gaim, ggm
[10:37:12] * wrs1864 wonders if the jabber room will become full, like it did at the BoF
[10:37:50] <wrs1864> ggm: I think it might be a good idea. I say try it, and if too many people scream, stop
[10:38:30] --- mtnviewmark has joined
[10:38:33] <ggm> I think it depends which UI you have. personally, It feels like I'm shouting but what else is new.
[10:39:10] --- hardie has left
[10:39:33] --- yushun has joined
[10:39:37] --- dblacka has joined
[10:40:30] --- warlord has left: Lost connection
[10:40:32] --- yone has joined
[10:41:01] --- hardie has joined
[10:41:31] <galvinjamesm> ggm: bold works for me if you can do it.
[10:41:44] --- hardie has left: Disconnected
[10:43:29] <mrose> 5 minute warning
[10:43:48] <ggm> or color. nah, thats like.. flashing HTML
[10:44:25] <galvinjamesm> mrose: I heard you the first time ;)
[10:44:36] --- rpayn422 has joined
[10:44:49] --- aen has joined
[10:45:41] --- andreas-b has joined
[10:46:48] --- CSVjohn has joined
[10:48:11] <mrose> two minute warning
[10:48:18] <wrs1864> ?
[10:48:18] <wrs1864> 2 second warning/
[10:49:24] <ggm> Andy Newton
[10:49:47] --- hildjj has joined
[10:49:49] <ggm> administrivia, agenda with 6 items. feel we'll use all our time [laughter] in the morning session if you don't know where you are.
[10:50:09] --- hildjj has left: Disconnected
[10:50:29] <ggm> any items for agenda bash?
[10:50:39] <ggm> no objections. move on to submitter-02
[10:50:42] --- kmurchison has joined
[10:51:34] <ggm> Harry Katz, Microsoft, open with brief overview of sender-id, Sender is just one of three. (could argue least important)
[10:51:57] --- hildjj has joined
[10:52:16] <ggm> merger of caller-ID, SPF proposals. out there and discussed for various lengths of time. during spec review, decided to split into three drafts to be discussed at various points today
[10:52:37] --- hardie has joined
[10:53:29] <ggm> what is submitter all about - extension to SMTP MAIL command. allows sender of message (MTA) to declare in the mail command what is the puported responsible address. in marid-core we'll get into what it is, how its derived, submitter is to allow the SMTP client to promote the info out of the RFC822 headers, into something in protocol, allow spoof checking. stricktly an optimization in message transfer process
[10:53:35] <hildjj> wrs1864: if the room becomes full, we can make it bigger.
[10:53:49] --- SAH has joined
[10:54:28] <wrs1864> is there a URL for the slides?
[10:54:38] <mengwong> not harry's slides, no.
[10:54:39] <ggm> example slides. [too dense to enter] shows 250-SUBMITTER adv. in EHLO response. and MAIL FROM .... SUBMITTER param added to MAIL command.
[10:55:21] <ggm> next example slide. Mailing List. same EHLO, MAIL FROM ... SUBMITTER with list owner added, reflected in header.
[10:55:30] --- paf has joined
[10:56:32] <ggm> third example. Mobile user, shows MAIL FROM ... SUBMITTER with mobile device, but from address differs. use of submitter would be mandatory. receiving system can spoof check
[10:57:26] <ggm> spec undergone revisions, at 02 level. [ tiny print I cant read from FRONT of room ] thorough discussion at design review in July. clarified mandatory/recommended, make it more clear how the value is to be set, interpreted.
[10:57:38] --- SamSilberman has joined
[10:58:01] <ggm> harry pauses to let people read. that was all he wants to present as slideware at this point, floor open for Q and Discussion.
[10:58:09] <ggm> Marshal does chair, calls for name, use of mikes.
[10:58:14] --- resnick has joined
[10:58:21] --- danwing has joined
[10:58:23] --- jakob has joined
[10:58:23] * hildjj has set the topic to: draft-ietf-marid-submitter-02
[10:58:33] --- ohm has joined
[10:58:33] --- peter has joined
[10:58:44] <ggm> Arte? Q Submit is now mandatory. [may not] work for all email programs. so qualified
[10:58:58] <mrose> martin duerst
[10:59:24] <ggm> Harry mandatory if claim to be compliant with draft, state use it. clearly if MTA does not support SUBMITTER it needs to ignore if received, client communicating with non-compliant MTA, needs to send without using, not block in any way.
[10:59:33] <ggm> Doug the PRA aspect, is that the IP claim by MS?
[10:59:41] <ggm> Harry want to defer to discussions at different point in agenda
[11:00:04] <ggm> Tim? confused about SUBMITTER being mandatory. if submitter advertizes SUBMITTER, sender must use?
[11:00:09] --- spe has joined
[11:00:19] <ggm> Harry the way the spec is written its defined as MANDATORY when puported sender address differs from real.
[11:00:35] <ggm> Tim but lots MTA now don't support. does that mean no longer able to receive if supported at receiving end?
[11:00:39] <mrose> s/puported sender address/purported responsible address (PRA)/
[11:01:01] <ggm> Harry no we dont want that. clear indication in an appropriate situation, if submitter extension is not adv. the client should not use it.
[11:01:08] --- tonyhansen has joined
[11:01:17] --- amelnikov has joined
[11:01:40] <mengwong> personally i think SUBMITTER should only really be mandatory, even when both sender and receiver support it, in the forwarding case. in other cases i feel that what would go into SUBMITTER should be in the return-path. if we tweak the draft in this direction, that would allow receivers to build a whitelist of all recognized inbound forwarding aliases, and reject submitter addresses not on that whitelist.
[11:01:41] <ggm> people you want to receive this from would use it. people you dont want mail from wont use it, wont get benefit. how do we save bytes?
[11:02:14] <ggm> Harry intent is that you are able to perform checks. if you are performing other detailed spoof checks, require 822 information validation, local policies require.
[11:02:50] <ggm> Jim Lyon MS. want to clarify required stuff. At some date in the future, SUBMITTER becomes required when submitter ad. not == From. not the case must use immediately.
[11:03:29] <ggm> Other point is there a performance optimization, well, person sending has no interest in doing so if they can predict it will be thrown away. achieves earlier throwing away, spammer will focus on people who will get mail instead of not get mail
[11:04:01] <ggm> Mike Thomas. seems to me, if I'm the spammer, first thing I do at sending MTA is not implement this, only club on receiving, if sending MTA not supporting, only choice is throw away. little heavy handed.
[11:04:22] --- nsb has joined
[11:04:26] <wrs1864> people seem to be missing the idea that the 2821.FROM is still being checked
[11:04:29] <galvinjamesm> is there any evidence to suggest that a spammer would actually check and even care that you're throwing away the message?
[11:04:31] <ggm> Harry not the initial intend. as Jim previously stated at some point in future, yet to be determined, absence does make
[11:04:39] <wrs1864> "nevermind!"
[11:05:04] <ggm> Mike good guys will do the good thing, Bad guys will not do the good thing, only recourse is throw away, or read more. bad guys are going to goad you into reading more for a long time, because not everyone will implement right away
[11:05:42] <mengwong> if submitter is not present, we fall back to mail-from. people are missing this.
[11:05:46] <ggm> Jim. even as a bad guy, no benefit to not implement. takes 2822 value promotes to 2821. if you do it, somebody can throw away sooner, if not, they throw away later. no value to you to waste resources to be thrown away
[11:05:55] <mengwong> people seem to think that if submitter is not present, we blow up. this is not true.
[11:05:57] <ggm> Harry corollary, bad guys wont do anything.
[11:06:52] <ggm> PHB. people have to think in spec writing, at some point people to adv. clients as RFC<xyz> compliant, good to make it clear they implemnt SUBMITTER, not have choice to implenment. other thing, how to fit into spam filter, if filtering 10m mails from source, some spam and some not spam, and person has impl. PRA, they are likely to stay in
[11:07:38] <galvinjamesm> I'm not clear on the optimization. even if I do it I have to check again later, right? I have to make sure that what the sender promoted matches what I received, don't I?
[11:07:41] <ggm> that cycle longer, rather than having IP address block put in. got to think about how this fits into spam filter mechanism. another point, IS going to be mandatory at some point, not this single spec, generate here. quite likely other forms of auth for lists, crypto mechanisms etc
[11:07:58] <ggm> think in terms of yes, 5 years from now it will go into bitbucket. wont spend $1M on spam filtering.
[11:08:14] --- leg has joined
[11:09:14] <ggm> ?Q1 not paying attention to most recent header. if formatting glitch,one app may stumble over, may cause different results in PRA. spammers good at detecting these things. add field to check, submitter checked against 822, doubled effort to auth, if is bad can reject at 2821 timeframe but in reality, most good spammers will get past intiial check. opening up to more risk. what IS the PRA being displayed.
[11:09:15] <mengwong> you have to do two out of these three things: (1) you have to check the SUBMITTER and require that the SPF evaluation returns a PASS. (2) you have to check the PRA and require that the SPF evaluation does not return a FAIL. (3) you have to check that the PRA matches the SUBMITTER (or, if it is not present, the MAIL-FROM).
[11:09:32] <ggm> Harry later agenda item to deal with this in detail PRA alg. 2nd not sure what is Q.
[11:10:00] <ggm> [Q2 is doug] certainty user sees, idea is to present identity he can rely upon. by adding another param, increases likelihood showing him wrong thing.
[11:10:13] <ggm> [sorry Q1 not Q2]
[11:10:30] <ggm> mentions eventually mandatory, does underlign IPR issue. implies must licence.
[11:10:37] <ggm> Ted Hardie
[11:12:28] <ggm> concerned people reacting as if not part of how SMTP normally handles service extensions. read drafts. this is service extension. adv. as normal service extension. discussed on list in context of problem highlighted here. MAIL FROM is actually BOUNCES-TO address. if there had been an equiv 821 thing to mean submitter, much stuff would be easier. I will channel Dave Crocker. useful if engaged if used for stuff not for spam? I think it would be. fits in this mechanism too, but worth eval from that perspecitve, useful part of SMTP exchange to know who submitter is. going to have to be checks does match later assertions but please see context
[11:13:04] <ggm> David. jim ,made claim will save b/w. reality most spam producers are not paying. by time processing is already in machine. so no benefit.
[11:13:27] <ggm> Harry. perform spoof check, can reject at 821 time, before have accepted data over the wire. if you accept msg data, can do additional PRA/hdr check.
[11:13:30] --- jis has joined
[11:13:34] <ggm> if its already in buffer, cant take it out of Q.
[11:13:42] <ggm> Harry can reject at end of mail command without accepting.
[11:14:06] <ggm> Dave processing not bandwidth. cannot save the bandwith, its in your receive Q. spam is small. will fit in TCP send q. will have ended while you process.
[11:15:03] <ggm> Hartun? Darnish? how does this make forging more difficult, would still send with from: sender, give own domain as submitter, result will be email arrives still looks same as today. still wrong sender add. wrong header line. only makes sense if we can ensure submitter arg finds way to recipients MUA. makes forging more easy not more difficult
[11:15:32] <ggm> Harry I dont think it changes forging ease. wether used or not, can register own domain, use in one header, domain in another header. just exposes that earlier on.
[11:15:35] <mengwong> Hadmut Danisch, author of RMX.
[11:15:52] <ggm> Hadmut how would recipient, normal user, detect as forged?
[11:15:54] <mengwong> i think we blacklist the spammer submitter in an RHSBL.
[11:17:02] <ggm> Harry good point. discrepancies in header being exploited this way need to be exposed in MUA, to alert user., show discrepancy. valid point. suggest true irrespective of use of SUBMITTER. because derived from 822 headers, possible and straighforward for MUA to determine PRA and present, this is the one which claims to be responsible but differs. are cases , not b&w, cases where its legit to have different addrs in different headers
[11:17:12] <ggm> Hadmut isn't it absolutely neccessary?
[11:17:12] <wrs1864> in retrospect, I wonder if the submitter I-D should have be the last thing discussed since everyone is bringing up points about other parts of SenderID
[11:17:14] --- ogud has joined
[11:17:15] <ggm> Harry I dont think so.
[11:17:46] <ggm> Hadmut 2nd q. calling it submitter gives it legal meaning, relates to identity, but its not. its just a ptr. giving you ability to find MARID record. wouldn't it be better to name it to avoid false meaning
[11:17:59] <wrs1864> "dave"!
[11:18:10] <ggm> Harry open to suggestions ifnot liked name. had this at last F2F MARID meeting. this is least objectionable name. if group wants other name, lets come up with it.
[11:18:19] <ggm> Marshall keep to <72 octets [laughs]
[11:18:23] <mtnviewmark> "HADMAT="
[11:18:31] <mtnviewmark> er "HADMUT="
[11:18:40] <mrose> tsk. tsk.
[11:19:05] <wrs1864> seriously, PRA= is probably the best
[11:19:20] <mengwong> good idea
[11:19:21] <mrose> i could live with that
[11:19:22] <ggm> John. merely promoting 822 to 821. no motivation for client to lie. forget if its a SHOULD or MUST, rejection happens. just distillation of whats in message
[11:19:26] <mtnviewmark> I'd be happy with PRA=
[11:19:41] <resnick> That was Jim Lyon.
[11:20:07] <mengwong> doug otis now talking about potentially hundreds of DNS queries, plus a nondeterministic PRA algorithm
[11:20:24] <ggm> Dave saving bw/ issues to be raised. idea is parsing and comparing to very long list allowed to use. very un-deterministic, protocol spec as now written implies 100s of DNS queries. another issue. if people are forced to comply and use, very likely to put resent-from so users are forced to use different from addr. becomes channel identifier, there
[11:20:46] <resnick> This is Doug Otis
[11:20:51] <ggm> already is one, called HELLO DOMAIN. in 2821 phase. replace submitter-id with HELO DOMAIN. short and deterministic.
[11:21:07] <ggm> [people mumble and speak quick. sorry for name typos. not much I can do. -ggm]
[11:21:14] <ggm> Andy is there a Question here?
[11:21:33] <resnick> Doug is suggesting a different mechanism. Out of scope of this discussion. As usual.
[11:21:34] <ggm> Doug potentially DoS threat. not addressed in spec. spec says 'timeout and try over' but now how handle nets.
[11:21:40] <ggm> Andy topic for protocol discussion
[11:21:50] <mengwong> Jim Fenton, now speaking, is author of the Identified Mail proposal.
[11:21:54] <ggm> "some dude whose name I can't spell I think called Jim"
[11:22:01] <mengwong> http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt
[11:22:17] <resnick> Jim Fenton, I believe.
[11:22:20] <ggm> wondering if there is an incentive to use it. do they use, or don'[t use decides if you get an optimisation. I don't think there is an incentive.
[11:22:40] <ggm> the b/w they save isn't their own. they're using zombies, using other peoples b/w
[11:23:17] <DouglasOtis> How about EULA:
[11:23:30] <ggm> Harry cant predict what spammers wont or will do. mechanism for legit users to have their mail validated earlier, may be benefit. in the absence of SUBMITTER, at some point in time, we expect people to start useing MAIL FROM at protocol level. so, the spammers will have the same issue with whatever MAILFROM using.
[11:23:41] <ggm> Jim would Q if MAILFROM has right semantics
[11:23:58] <mrose> someone tell me if i got this wrong: receiving MTA advertises SUBMITTER, sees SUBMITTER on MAIL FROM, runs algorithm, if pass, accept MAIL FROM, after DATA, calculate PRA based on DATA and see if it matches SUBMITTER. if SUBMITTER not advertised/presented, then still calculate PRA based on DATA and see if passes.
[11:24:06] <ggm> Harry thats why we're using SUBMITTER. want people to have ample opportunity to deploy support, and at some point in time, orgs may choose to do this.
[11:24:26] <paf> mrose: this is what I see as well.
[11:24:29] <ggm> Jim wondering what Q is. I think you can get some benefit if there is some way to make it mandatory. so Q is, is there a way in SMTP ext context to make it Mandatory?
[11:24:38] <ggm> Andy suggesting SMTP ext to say SUBMITTER IS MANDATORY?
[11:24:44] <ggm> Jim no, too disruptive
[11:24:56] <ggm> Harry I agree. so have to allow for gradual adoption
[11:25:13] <mengwong> mrose: correct. at some point it will be reasonable to assume that in the absence of SUBMITTER that means the sender MTA is SUBMITTER-aware and by omission of SUBMITTER implies that MAIL-FROM is the PRA.
[11:25:24] <ggm> Mike Thomas., problem as I see it, spammers have to get 'down the pipe' as far as they can. if don't have policy to require, wont put it in.
[11:25:34] <mengwong> this describes the most common use case, MAIL FROM:<mengwong@dumbo.pobox.com> ... From: mengwong@dumbo.pobox.com ... with no other ornamentation.
[11:25:35] --- vlevigneron has joined
[11:25:49] <ggm> seems to me good guys will do submitter test, will succeed, bad guys wont, passes to next stage == from validation. good guys do two tests, bad do one. superfluous.
[11:25:55] <ggm> Harry we disagree
[11:25:59] <mrose> paf: so the delta here is being able to calculate PRA acceptability on MAIL FROM instead of DATA
[11:26:02] <ggm> Brent. clarification Q.
[11:26:22] <resnick> mrose: right
[11:26:24] <mengwong> now asking a question is Rand Wacker from sendmail.
[11:27:04] <mrose> resnick: good thing? bad thing? "who cares" kind of thing?
[11:27:05] <ggm> purpose of PRA, SUBMITTER, is for ML and forwarding services, add header to say 'cant validate orig, we made this hop' so validate to most recent hop. for MX secondaries, there is no recommendation for them to change. message comes, received, will get to primary, with no change, submitter/PRA is original state as at MX, wont auth be broken because the MX is not validated.
[11:27:21] <ggm> Harry if I understand scenario correctly its covered by DNS publication
[11:27:48] <ggm> Rand, thinks data gets lost if through MX which doesnt support
[11:27:50] <ggm> Harry yes
[11:27:53] <resnick> mrose: closer to "who cares" than to "good", but not "bad" as far as I can tell.
[11:27:59] <ggm> Rand so web pushes outwards, needs Secondary to do it for you
[11:28:01] <ggm> Harry yes
[11:28:05] <mengwong> the point that rand raises is true for any antispam technology.
[11:28:10] <mtnviewmark> note: you currently have to push the web of trust out to all your secondaries
[11:28:22] <mengwong> everyone is either a sender or receiver. a secondary mx is on the side of the receiver.
[11:28:55] --- peterd has left
[11:29:09] --- AndrewD has joined
[11:29:11] <ggm> Hadmut. another Q. sender has choice to use. restricted if only can give good identity. pointing to MARID rec or not. if has good record can give, if doesn't doesnt give and still submit msg. msg tx in both cases. 2nd Q!. did not follow all details of MARID. decided to do before or after header? if not, go back one step and discuss when MARID verify done?
[11:29:12] --- fenton has joined
[11:29:23] --- dblacka has left: Disconnected
[11:29:33] --- dblacka has joined
[11:29:46] <ggm> Harry so, do we do this check before msg has been transmitted. thats the whole idea. if msg doesnt contain SUBMITTER, has to get 822 headers, to then perform checks.
[11:29:58] <DouglasOtis> How is an authenticated and authorized EHLO domain less secure or informative than this PRA paramenter? The EHLO domain can be checked with a single lookup and does not require checks against the 2822 headers.
[11:30:02] --- peterd has joined
[11:30:37] <mengwong> i think harry just said "yes" where he meant "no".
[11:30:38] <ggm> Hadmut maybe I didn't ask correctly. IF spammer, doesnt wnt to reveal own domain, submits without SUBMITTER. you have to do check after receiving complete data. so why do we do it sometimes before, sometimes after, if always wind up having to do verify after, in case where absent.
[11:30:40] <wrs1864> DouglasOtis: I don't think this jabber session is a good place for such discussions
[11:30:44] <mengwong> a lot of these questions are arising from a misunderstanding of the protocol.
[11:31:23] --- marcos.sanz has joined
[11:31:31] <ggm> Barry Lieber. want to echo what Phil said earlier. when have enough goodguys doing it, can refuse either by RFC or de-facto, once we have enough good guys. if we dont have way to tell good guys cant do that.
[11:31:46] <ggm> Hadmut eg for 3 years we have to do after, then can do before
[11:31:53] <mengwong> the spec does not require SUBMITTER when MAIL FROM is the PRA.
[11:31:57] --- CSVjohn has left: Disconnected
[11:32:00] <ggm> Harry hesitant to put timeline up. need to allow some time for it to happen
[11:32:04] <mengwong> we should never get to a point when SUBMITTER is mandatory.
[11:32:19] <ggm> suspect over time, may find certain large ISPs wont accept, one of those things become defacto mandatory before dejure
[11:32:20] <resnick> For the notes: Barry's name is "Leiba"
[11:32:34] <mengwong> now speaking is Patrik Fältström from cisco.
[11:32:48] <wrs1864> mandatory in the sense that if 2821.FROM != PRA, then SUBMITTER= must be used
[11:32:53] <DouglasOtis> We already have EHLO mandatory.
[11:32:54] --- marcos.sanz has left
[11:32:57] <wrs1864> (if the receiver supports it)
[11:33:01] --- marcos.sanz has joined
[11:33:05] <resnick> (ggm: fear not; it's easier to know the players when you've seen them all before. :) )
[11:33:30] <resnick> (I'm happy to keep filling in blanks)
[11:33:59] <ggm> PAF. confused. two discussions mixed here. one is impl, protocol, the other is policy using solution. I think regarding protocol, 2way exchange, receiver can always say no, up to receiver policy, its up to them. most imp. part is that receiving party can flag, let sender know why rejected, let sender try again with credentials. do understand people want to verify tech proposal is possible to be used, impl policy they want, but discussion must clearly separate policy suggestions to implement, from tech solution. hear too much of what policies should we impl.
[11:34:38] <ggm> Harry thankyou. excellent point. SUBMITTER is tech solution for receivers to impl. policy they want. little bit of policy, we do suggest MANDATORY/OPTIONAL and that defn steps into policy arena. but attempting to provide tech soln.
[11:34:49] <resnick> (I have no idea who this is)
[11:34:53] --- suz-isc has joined
[11:35:01] <ggm> Serich from Ericcsson. looking at this wrong way,. not penalize spammers, incentivise goodmail to pass through filters faster later.
[11:35:23] <ggm> Harry thanks. certainly possible. in extreme case, messages not accepted, in the future.
[11:35:25] --- nsb has left: Disconnected.
[11:35:32] <ggm> Suresh doesnt have to be that aggressive.
[11:35:39] <mengwong> edwin aoki from AOL.
[11:35:43] <ggm> ? from AOL agree with PAF. gives us tool.
[11:36:09] <ggm> gives us another piece of puzzle all of us can use to determine mail validity. look at it in that context. one tool in many not THE tool/plicy
[11:36:32] <ggm> Jim Fenton. Q for person from AOL maybe. thinking about large service providers.
[11:37:12] <ggm> do we think large Service Provider will impl policy of not acceping mail without SUBMITTER any time in the (near) future, given that they have to deal with helpcalls, when throw switch, sender domains stop being accepted because dont do it. Hard switch to throw
[11:38:08] <ggm> Edwin/AOL dispite what I would LIke I can't decide policy [laughter] but spam is a huge problem for us, continue to look here and other WG, to tighten noose around spammers, already publish SPF, committed to using other methods as input into existing policy, not to block anyone. have grades of goodness and badness, this will be another mech.
[11:38:30] <ggm> Jim if using this as rating criterion, achieve any efficiencies? if one of many inputs, do you have to accept msg to do others?
[11:38:38] --- RandyG has joined
[11:38:52] <ggm> Edwin good point, what do we save? bw or processing, we have long processing tree, this might short circiut processing not acceptance/net side
[11:39:33] --- spe has left
[11:40:02] <ggm> Phil Hallam B (PHB) large ISPs are like Elephants or container ships, hard to get them to change course, small ISPs, ents managing own mail different. when selecting ISP, savvy customers will ask in future ;whats prob mail is reliable through this ISP. stuff like this helps me to judge that probability., doesnt depend on secret knowledge. sending ability of ISP will be transparent and get better accountability in industry as a whole
[11:40:03] --- hta has joined
[11:40:05] <ggm> Harry any more Q?
[11:40:28] --- gih has joined
[11:40:37] <ggm> Andy [chair]
[11:40:46] <ggm> is there a concern that sending MTA must use SUbmitter or mail rejected?
[11:40:52] <ggm> (must know to use)
[11:41:02] <ggm> Andy no comment? apparently not.
[11:41:35] <ggm> PAF I think more important, extemely important, sender get inf. on why something rejected afterward. not wrong to flag before, but the absolute neccessity is to know why, little tired of all MTA today reject without why
[11:41:47] <ggm> Harry I think its in spec, return codes specified. if gaps want to hear, will amend.
[11:41:54] <ggm> Andy. move on to protocol discussion.
[11:42:01] <mengwong> Mark Lentczner will now discuss the protocol.
[11:42:12] <ggm> [sorry about the name confusion guys. Pete is doing a sterling job correcting 'em -ggm]
[11:42:16] <mengwong> Mark is co-author on the marid-protocol-00 draft and on previous versions of the SPF drafts.
[11:42:48] <ggm> Mark: few minor things in draft, will attempt to fix in next draft. will discuss first, then only one big issue to discuss.
[11:42:52] <resnick> Meng is helping. :)
[11:43:04] * hildjj has set the topic to: draft-ietf-marid-protocol-00
[11:43:12] <jis> So how "deep" does the protocol go?
[11:43:19] <jis> (this is me asking, as an aside)
[11:43:45] <jis> I.e., if I get a connection from client.foo.bar.baz.com do I look for an spf record for client.foo.bar.baz.com or baz.com?
[11:43:55] <mengwong> a:foo.com/29 is obvious to humans, but a:open.24/7.bizarro.com may be legal and may confuse parsers; this will be fixed in the next rev of the ABNF.
[11:44:03] <ggm> first minor issue. somebody found parsing error with CIDR masks, use of slash in macro. one person found, will work with them to fix. issues with EBNF in grammer. ok back up. Protocol document, clear intent is that this is the mechanics doc. dont want to get into issues apart from mechanics. only defines format of records and what it means to check them given mailbox and IP addr. thats what it does based on SPF 'classic' format. backwards compat with large number of recs.
[11:44:11] <mengwong> jls: the protocol does not search up the domain tree.
[11:44:16] <resnick> heh: ABNF
[11:44:28] <resnick> (RFC 2234)
[11:44:35] <jis> tnx
[11:44:37] <mengwong> explanation string will be internationalized in some way. this is also a minor nit.
[11:45:26] <mengwong> the explanation string is done like this: v=spf1 -all exp=_exp.domain.com .... _exp.domain.com TXT "please see http://whatever"
[11:45:39] <ggm> has been concern about record format, EXP string, concern about I8N. EXP is rejection msg. person publishing record, can specify string, sent back by relay to sender, allows to tell that person 'forget it, cant use my domain this is why' -string expands to dns name, -> TXT rec, with variables for expansion, that text is used for return. common use is URL to get lots of detail. I believe pobox.com is done like this. example does this as well
[11:45:40] <resnick> Lordy! That's quite a mechanism!
[11:45:56] <mengwong> it's a modifier, technically, because it uses an = sign :)
[11:46:22] <mengwong> so the concern is that you won't be able to say something like "plÎase sÈÈ http://whatnot"
[11:46:31] <ggm> open to anything which will fix this, tell params clearly. 8 bit octets allowed, defined in this doc to 7 bit ascii. charset is implicit. of course, if put URL, whats at other end can be in any lang. I dont see better solution
[11:46:49] <mengwong> squishing UTF-8 into plain old us-ascii SMTP is an interesting challenge
[11:46:56] <ggm> Martin ? datapoint. URI or URL, content cannot only be in any lang, can be negotiated. not sure thats enough but its good
[11:47:06] <resnick> Martin Dürst.
[11:47:10] <peter> mengwong: at least we can send those through Jabber (since XMPP is all UTF-8 :-)
[11:47:13] <ggm> unnamed person. security impl clicking on a URI?
[11:47:32] <mengwong> mike thomas: security considerations of "please see http://nsfw/goatscx/
[11:47:37] <leg> yeah, i never click on a url without already knowing what the page looks like. but since i know what the page looks like, i never bother clicking at all.
[11:48:22] <ggm> Mark: yes. URL as far as security concern. person who receives URL back. guy rejected because domain sent, claim comes from mark@example.com. on road, sent through bizarre MTA, response code, back from MTA, is generated by *my* MTA. so its not evil
[11:48:23] <mengwong> mark's response: that's okay because the exp string is controlled by the sending domain, and is seen by users of the sending domain. if your ISP is evil, this is a problem.
[11:48:28] <mrose> peter: so we should put jid: uris in spf records..
[11:48:32] <ggm> [he's ignoring it being phreaked -ggm]
[11:48:44] <mengwong> i know, let's do cryptographically signed URLs.
[11:48:51] <hildjj> mrose: xmpp: URIs; we're working on building up that ID.
[11:49:02] <ggm> Mike T. but, if I'm on road, bounces come from people I dont know, with URL 'click on to find more stuff' -could be porno stuff.
[11:49:16] <ggm> Mark but happens now with content.
[11:49:24] <ggm> Mark T but this is to get the info about what the bounce is about
[11:49:50] <ggm> Mark no, at option of domain publisher, just TXT also error code, there is an SMTP error code, which bouncing MTA rejects then whats in EXP string.
[11:50:07] <ggm> Mark T no... creeeps me out from phishing perspective
[11:50:11] <ggm> Mark no, its from your MTA
[11:50:13] <peter> ... gone phishing ...
[11:50:37] <ggm> Mark no its ML domain, it comes from there.
[11:50:50] <ggm> nothing has changed. its not stopped now.
[11:51:04] <ggm> MarkT but you're making it a standard
[11:51:09] <ggm> [shrugs]
[11:51:30] <ggm> MarkT say "way to do i8n is 'click on this URL' its dangerous"
[11:51:39] <fenton> It's Mike T, not Mark T
[11:51:40] <ggm> MTR its a little too late to get rid of the web [laughter]
[11:51:51] <ggm> [aaaargh sorry]
[11:52:11] <ggm> <draft author> back to large item.
[11:52:32] <ggm> versioning and reference to what this record refers to. 100,000 domains publish this format, compatible with draft.
[11:53:03] <mengwong> mark now discussing the backward compatibility agenda item, which I have summarized at http://spf.pobox.com/slides/molson/01.html
[11:53:04] <ggm> is certainly the case, published to be seen against domains in mail address. if takes narrow view, thats what they publish.
[11:53:09] <mengwong> (click on the RHS of the slide to go forward.)
[11:53:31] <ggm> now applies to PRA, concern about how to handle the concerns. going to outline the concerns I have heard.
[11:53:56] <ggm> people publishing records, breaks POLA when their domain used in the other identity. forward compat. concern.
[11:54:16] <ggm> equal backwards compat concern. new people will publish expecting ONLY checked against PRA domain, but old s/w checks against MAILFROM.
[11:54:38] <hardie> POLA=principle of least astonishment
[11:54:40] <ggm> third concern, may be as many as 100,000 publishing, want to keep momentum
[11:55:22] <ggm> dont think mechanics of solution are important. can change version numbers, have to publish new, want back compat, by downgrade. add modifiers/mechanism to make failover work appropriately. what matters is which are we concerned about.
[11:55:37] <ggm> is it, that existing publishers will be checked in new way, new people checked in old way?
[11:56:27] <ggm> My position is, its the vast majority of domains/publishers would publish same for both. slight additional things in either direction, no security risk. looked and asked people and can see conceptual difference, but do not see problems.
[11:56:39] <ggm> Andy. can you state what the proposal is if we need to differentiate?
[11:56:55] <ggm> Mark simple solution is to change version string.
[11:57:30] <mengwong> ted hardie channelling John Klensin, author of rfc1869 etc.
[11:58:32] <ggm> Ted Hardie. channelling John Kkensin. John, long time ago tried to point out to HTTP wg trying to change GET vs adding hack host: header to get round addr exhaustion, doesnt matter how many you have now, matters rate of change. my anticipation is that uptake rate that current number of publ domains will be small % of total. makes it clear is we should change version number, make it clear about POLA, but also which spec to look at. other one is still out there in the wild. people might continue to publish SPF1 meaning mailfrom, for some time.
[11:59:05] <ggm> wg has spent enough time, pragmatical decision goes against fundamentals even if current use space doesnt use them differently. look at rate of change to make decision and I recommend changing verison string.
[11:59:11] <mengwong> Margaret Olson, constant contact.
[11:59:12] <ggm> Margaret Olsen. second what ted said.
[11:59:52] <ggm> when look at domains out there as total vs ones publishing. likelihood SPF1 and domain match goes down dramatically. most domains not technical. possibility for confusion is enormous. I am concerned about momentum.
[12:00:13] <ggm> want to get it out there quickly. mis or old info, old tools, things wont go smoothly, will inject delay. strongly recommend change version #
[12:00:18] <mengwong> rand wacker at sendmail now.
[12:00:22] <ggm> Rand. Q originally came up to ask.
[12:00:54] <ggm> in order to become SPF complaint, has to publish and do SRS. sender-id publish and header to do PRA. my concern is, publish rec, do one or other doesnt make compliance with both.
[12:01:11] <ggm> nice to have backwards compat but not reaility. second teds indication the adoption curve is it not existing base
[12:01:17] <ggm> Doug Otis
[12:02:14] <ggm> SPF differences, one is doing different function. some protection against viruses, getting mail through back door. sender-id ignores entirely. motivation behind SPF-1 recs is obliterated by Sender-iD because ignores field. if going to change something, dont change version, change to different record. need to close back door, continue SPF-1 make it something different.
[12:03:00] <ggm> Mark. if we did change it, could call it SPF-2 but could call it something else. keeping format same doesnt make much different. lots of reasons why why it is. if change version, allows for people to do both. Will take input as 4th choice in decision
[12:03:08] <ggm> Doug evolutionary path implied. runs into conflict.
[12:03:35] <ggm> Mark didn't say it was a 'subsequent' version. nothing was said was implying what it means
[12:03:45] <mengwong> someone has raised the TXT spectre.
[12:04:13] <ggm> <missed name> using TXT. not happy. can't work if peoiple use TXT for other purposes. take it into DNSEXT. kill old rec, make base rec in DNSEXT [applause]
[12:04:16] <mengwong> audience applauds the suggestion to get a new RRtype.
[12:04:27] <ggm> Mark current version does suggest transition to that.
[12:05:03] <ggm> Mark large explosion of new RRtype, concern existing s/w unable to use new DNS rrtype easily enough. large number of domains use DNS providers who cant do this.
[12:05:05] --- dcrocker has joined
[12:05:08] <suz-isc> speaker re: TXT was David Hankins, ISC, who should have identified himself :)
[12:05:13] --- ggm has left
[12:05:22] --- ggm has joined
[12:05:24] --- leifj has joined
[12:05:34] <ggm> PHB intention is to make mail work, not a killer DNS app.
[12:05:43] <resnick> Can the gavel fall hard on this particular topic?
[12:05:47] <mengwong> killer app for DNSEXT, specifically.
[12:06:00] <ggm> since not shown to be >60%, its not going to be anything but a TXT for a while.
[12:06:17] <ggm> PHB if we do add version string, add minor version number state to have small non-backwards-breaking changes.
[12:06:35] <ggm> prefix, can distinguish record in TXT with prefix. perfectly adequate way to extend DNS.
[12:06:36] --- edmundo.cazarez has joined
[12:06:38] <ggm> Roy Arends
[12:07:11] <ggm> want to comment on TXT. during DNSop meeting, somebody will give presentation on 3597 interop of DNS. seen some information on that one, is no big issue there. using new RRtype.
[12:07:15] --- mitsubachi has joined
[12:07:23] <ggm> folks interested in this come to DNSOP.
[12:07:35] <ggm> Andy please back to issue of proto version. can discuss this, but lets finish off this topic
[12:08:00] <ggm> Mark Q for last speaker. prefix is adequate or prefix should be changed. (for PHB)
[12:08:08] <ggm> Mark ok so you meant prefix in domain name.
[12:08:16] <ogud> the 3597 interop report will be in DNSEXT tomorrow at 9 not DNSOP today
[12:08:18] <ggm> [not using mike bad bad PHB]
[12:08:44] <ggm> Marshall poll room if feel version string must not change? no clear signals from room.
[12:09:00] --- dcrocker has left: Disconnected
[12:09:06] <ggm> since nobody in room feels sufficiently aggrevated, Mark, tell us way to rev string keeping what PHP said in mind.
[12:09:31] --- dcrocker has joined
[12:09:52] <ggm> Mark was very clear, SPF-1 check for specific string. have option to call it V=SPF-2 or V=MARID, or V=SENDER-ID is fine, V=PRA is fine. anything is fine.
[12:10:02] <ggm> Andy. be more clear [laughter]
[12:10:08] <ggm> Mark just dont call it MARK [laughter]
[12:10:27] <mengwong> jutta suggests sender-id-1-N
[12:10:30] <ggm> <floor> sender-id-<x>-<x> to get the back compat.
[12:10:44] <ggm> Andy let draft authors present to ML.
[12:10:53] <mengwong> Jutta Degener, sendmail.
[12:11:10] <ggm> Mark Andrews. whatever do, make sure label does not match valid labeltypes
[12:11:28] <ggm> PHB. if changing labels, few other things like extensibility, need changing.
[12:12:10] <ggm> Mark I dont think thats strictly true. if we change string, rest all goes through, s/w checking mailfrom not these, will be quickly revved. but if we change parse, we introduce large amount of delay. extensibility has been discussed all ways.
[12:12:55] --- danwing has left: Disconnected
[12:12:56] <ggm> Mark there is extensibility in here, even if it doesnt match everyones wants. does cover large amount of options, without going overboard. format has been looked at, are problems /concerns, but it can be parsed.
[12:13:13] <ggm> argue strenuously, for rapid deployment, even if change format #, dont' mess with semantics.
[12:13:16] --- Shevek has joined
[12:13:22] --- yone has left: Disconnected
[12:13:24] --- yone has joined
[12:13:34] <ggm> if body as a whole says 'dont do this' then fine, but I dont think we're going there.
[12:14:03] <resnick> Margaret (who didn't announce her name.....bad Margaret)
[12:14:04] <ggm> Marg want to second that. deploy quickly.
[12:14:20] <ggm> change minor or major version later if want to improve syntax
[12:14:49] <ggm> Mike? using the top level domain, only one TXT?
[12:15:01] <ggm> Mark no, can have as many as you want. can have separate 2 TXT recs, each 255.
[12:15:18] <ggm> Mike so if I have TXT at example.com, only one RR <floor> NO! like A can have multiples.
[12:15:24] <ggm> Mark and draft speaks to that issue
[12:15:35] <ggm> Mike <sorry>
[12:15:44] <ggm> Mark do we now have closure on the version string, format issue?
[12:16:04] <ggm> Leaves us with 2 issues. one is TXT vs custom DNS type, the other is publish at top, or under some sub-domain name.
[12:16:15] <ggm> Andy calls Ted Phelps to the mike
[12:16:28] <ggm> Ted forget what he wanted to say [after walk to mike]
[12:16:39] <mengwong> Ted Hardie, from Qualcomm.
[12:16:58] <ggm> Mike. multiple recs, over UDP.. do I blow MTU...
[12:17:07] <ggm> [oh please, not DNS in this room -ggm]
[12:17:20] <ggm> Mark gives tutorial on this issue
[12:17:33] <mengwong> a lot of people are now getting up to the mike to say that overloading TXT is aesthetically undesirable.
[12:17:40] <ggm> Mark changing type, because we expect old TXT to go away
[12:17:54] <hildjj> can open. worms everywhere.
[12:17:54] <ggm> Mike why are you inviting this problem, when subdomain makes it go away
[12:17:58] <ggm> Mark dont conflate
[12:18:04] <mengwong> now we have to discuss the subdomaining issue, where for example we do _spf.example.com TXT ...
[12:18:05] <wrs1864> If we create a new record version, we should have a spf1: mech to read v=spf1 records
[12:18:13] <ggm> Andy both
[12:19:02] <ggm> PHB. argue for prefixes, on basis that the worst case, wildcard, loose ability to select ONLY records of type <x> . thats the worst case. if use prefixing, need to use version string to make sure what you get back is what you want, not just wildcarded in. apart from that it just works fine.
[12:19:03] <resnick> (**Chairs: Please remind folks to give their names, even if they've come up before. Better for the minutes taker.**)
[12:19:08] <mengwong> phillip hallam-baker argues against prefixes because if you have to do a wildcard (eg for something.apple.com) you lose the ability to select a specific _spf prefix: *.apple.com TXT will return both _spf.apple.com TXT and _otherproto.apple.com TXT.
[12:19:23] <mengwong> er, i guess he argues for.
[12:19:33] <ggm> Mark record type specific issue? if you have a prefix it doesnt matter, wildcard applies to anything.
[12:19:46] <ggm> [yes he argued for, with version string]
[12:20:01] <ggm> PHB worst case is 'back where you are today' all in the bucket.
[12:20:02] <Shevek> Very nice, if you can make wildcards, until someone asks for 'everything except _senderid'.
[12:20:06] <mengwong> so in that situation, the worst case is that we're just back to where we are today.
[12:20:14] <ggm> Mark IF we use a prefix, because of wildcards, TXT rec format requires version string
[12:20:31] <ggm> PHB right, not a substitute, what is defined is syntax, not set of operable semantics.
[12:21:10] <mengwong> this is a good point.
[12:21:14] <ggm> PHB nice if we have RR whose property was XMLstring. if we had that, wouldn't argue for different XML rec, we'd do SRV and prefix. and then we wind up with same position we have today. its logical approach. not bad architecture.
[12:21:21] <mengwong> this means that _spf and _whatever are no worse than the current situation.
[12:21:28] <ggm> Olafur
[12:22:09] <mengwong> "new types will have a very rapid deployment"
[12:22:13] <ggm> As to PHB, last statement, repeat statement one of his favourite persons said; if you want XML rec, send text, we'll entertain in DNSEXT. as to new or old types, new types will have rapid deployment if people upgrade to modern s/w. some clientside have problems, undersood
[12:22:18] <mengwong> next up, Jim Lyon will respond saying "new types will not have a very rapid deployment".
[12:22:25] <wrs1864> heh
[12:22:25] <ggm> as to wildcards, I'm biggest hater.
[12:22:26] <wrs1864> yeah
[12:22:44] <ggm> lots of people dont realize that, dont understand how they work.
[12:23:08] <ggm> they make all names exist to infinite degree. makes issues. size of DNS pkt no problems. EDNS0 allows for this.
[12:23:22] <ggm> there is tcp fallback.
[12:23:47] <ggm> Mark 2 quick clarifications. hear conflicting things about wildcards. PHB said only used for recs without the TXT
[12:24:01] <wrs1864> that's ted, isn't it?
[12:24:02] <ggm> Olafur but it also instantiates names which dont exist as existing with that TXT.
[12:24:15] <ggm> no, thats Olafur co chair fo DNSEXT.
[12:25:00] <ggm> Mark I have example.com, with hosts with only A recs for 1.ex 2.ex. 3.ex I want senderID rec, under x_y_x_1.example.com with TXT. now I publish wildcard, for hosts 2 and 3.
[12:25:28] <ggm> Olafur that IS possible. doesnt matter
[12:25:39] <ggm> [ggm shouts clarification about populating the namespace]
[12:25:44] <mengwong> if you have host2.example.com, a wildcard for *.example.com will return for _spf.host2.example.com.
[12:25:50] <mengwong> is that true?
[12:26:07] <wrs1864> I think so
[12:26:14] <ggm> PHB there are two issues. if somebody uses wildcard, will MARID records be ambiguous
[12:26:16] <hta> if A record for 2.ex exists, wildcard for *.ex will not be returned for x_y_z.2.ex.
[12:26:22] <ggm> second issue, if somebody uses wildcard wil lthey not work
[12:26:29] <ggm> third, does MARID stop wildcard working at all.
[12:26:32] --- orange has joined
[12:26:34] <ggm> last one, we know the answer is no.
[12:26:46] <ggm> certainly not going to make MARID record break, its more specific
[12:27:27] <ggm> the thing you get is ambiguity, if wildcards used. at moment, because we use TXT, we have it anyway. use RRtype, solves it, use prefix, you have the ambiguity if they use wildcard.
[12:27:58] <ggm> Mark. will resolvers work?
[12:28:09] <ggm> there was an invite to DNSEXT tomrrow to know about that
[12:28:20] <dblacka> mengwong: if host2.example.com exists, a wildcard for *.example.com will NOT match _spf.host2.example.com.
[12:28:27] <ggm> Mark A. vast majority of NS deployed can take any new RRtype at any time, been true for a long time
[12:28:47] <mengwong> jim lyon from MS will now say that this isn't actually true for a significant minority of NS deployed.
[12:29:28] <ggm> Doug C. point of order. arent WG meant to make progress, not visit old topics. I'm unclear about the status of these topics. can we get comment from the chairs please
[12:30:19] <ggm> Marshall. it has use. this group has never met at IETF. I know raised in ML, oob meetings, useful to have crossover review, have DNS people beat us up, the reason why we
[12:30:20] <ggm> scheduled 2 extralong sessions was to get over this.
[12:30:29] <resnick> Dave Crocker, btw.
[12:30:29] <ggm> Mark Andrew, resolvers always able to handle this. app has to parse it.
[12:30:38] <ggm> Andy N. what about the APIs
[12:30:46] <ggm> Mark Andrew they say 'get me record <foo>" and just pass.
[12:31:28] --- yakovsh has joined
[12:31:28] <mengwong> windows dnsquery is not actually going to be able to do 'get me record <foo>' until the OS has been revved.
[12:31:35] <mengwong> and revving windows means longhorn.
[12:31:53] <ggm> Jim Lyon. with respect to wayne, I think he's wrong on this one. MS, APIs, I thought we had the worst DNS on the planet but Ive seen worse. but MS is not going to come back with new RRtype until you rev the client. if using MS firewall, wont come back until both client and FW revved
[12:31:53] <mengwong> or later.
[12:31:54] <ggm> Mark: and thats versions not yet written right?
[12:31:56] <ggm> Jim yep.
[12:32:02] <mengwong> "by revving you mean to a revision that has yet to be released?" "by revving you mean to a revision that has yet to be designed."
[12:32:17] <ggm> Olafur thats wrong. latest MS server version can list types it doesnt understand,
[12:32:33] <mengwong> jim: latest windows can handle new rrtypes in AXFR or a dynamic update until the next reboot.
[12:32:38] <ggm> Jim but only if secondary, and not rebooted since receiving it by D-DNS. its not that simple
[12:32:43] <mengwong> but it's not like they're as natural as A, MX, or TXT.
[12:33:01] <ggm> one of the goals was to avoid having to install new s/w if we go to new rrtype we lose that goal
[12:33:13] <ggm> Pete Resnick new client or new server.
[12:33:24] <ggm> Jim new OS s/w on server that runs DNS server.
[12:33:41] <resnick> Actually, question was: New client software or new OS software?
[12:34:09] <ggm> Jim one more point. txt is transitional but new rrtype in pipe. then problem is publish txt or rrtype, if publish rrtype its invisible to many, if publish both, the adv. is minimal.
[12:34:15] --- edmundo.cazarez has left: Logged out
[12:34:29] <ggm> Mark there IS advantage, publish new RR doesnt conflict, clients get only that thing. want to summarize
[12:34:52] <ggm> in this debate, everyone involved in drafting said 'new RR is right thing to do. with no dissent' BUT .. [laughter] practical consideration.
[12:35:18] <ggm> but draftees, decided new RR may be ultimate right thing to do, if we could make it happen we'd do it. there was practical concern.
[12:35:40] <ggm> desire to have this thing phased in over 6 months.
[12:35:50] <ggm> Marshall chairs queue
[12:35:51] <ggm> Ted.
[12:35:53] --- edmundo.cazarez has joined
[12:36:16] <ggm> concerned this all came up because of talking about a version string [laughter]
[12:36:18] <ggm> remind of surgeons command written on patient 'see other leg'
[12:36:20] <ggm> this is a compromise.
[12:36:32] <ggm> we knew we'd be a bit queasy with this decision.
[12:37:49] <ggm> its a useful compromise. believe we will get to point where new RR will be deployed, use unknown RR draft go to RFC and deploy. but meantime we have ample evidencve we have deployment problems NOW using unknown RR, we understand being worked through, encourage you to say 'am I queasy, or will this break the net' if its just making you sick, we're all a little nauseated. its a compromise. keep goals/time in mind.
[12:38:08] <ggm> Olaf Kolkmann. I'm compromise person
[12:38:23] <ggm> But.. this feels so bad. changing arch to cope with broken middleboxes. hurts.
[12:38:34] <ggm> is as if the leg was already amputated [laughter]
[12:39:20] <hildjj> it's not just broken middleboxes. *many* of the resolver libraries can't even do SRV. Much less other RR types that they don't know about.
[12:39:21] <ggm> Sam weiler. Olafur talked about wildcards, was correct as far as names they applied to. absent DNSSEC they don't appear on wire between auth servers. may be other ways to do synthesis, wouldn't cause problems to resolvers, would to servers.
[12:39:38] <ggm> Mark I'm trying to work out what we do here.
[12:39:57] <ggm> Sam you may be able to do a synthesis on the AUTH server, which doesnt use standard semantics.
[12:40:04] <ggm> Mark smart servers, to answer
[12:40:08] <ggm> Sam only those servers.
[12:40:28] <ggm> Dave problem with microsofts server accpting new RRtypes.
[12:40:48] <ggm> two domainname surveys show the vast majority of servers are NOT ms.
[12:40:56] <ggm> Mark its also receiving MTA have problem.
[12:41:08] <ggm> Andrew Donaghue
[12:41:25] <ggm> this is mta to mta protocol. smaller pop of incapable servers than when you think 'all ms clients'
[12:41:45] <wrs1864> no, this is not an MTA to MTA protocol, spam filters can and will use the SenderID/SPF system also
[12:41:58] <ggm> not all ms clients used as MTAs. this reduces the pop of devices being good guys being MTAs. I'm preparing own ID with RRtype, now I find out here, its quick way to oblivion
[12:42:06] <ggm> Mark % of MTA running MS?
[12:42:14] <yakovsh> isn't there a sruvey on this?
[12:42:23] <ggm> Rand from sendmail
[12:42:34] <wrs1864> there was one done by djb, but it is years old
[12:42:46] <yakovsh> rand just mentioned the percentagbe about 5%
[12:42:53] <ggm> rate MS under <5% so its the 4th most popular MTA. MS run MTAs are 10-20%
[12:43:15] <yakovsh> wrs: aren't dns servers serving these records also an issue?
[12:43:24] <wrs1864> yes
[12:43:32] <ggm> Mark so 10-20% will be HOSTED on MS, so unable to read RR. non-trivial percentage. but if making architectural decisions for broken MTA and want to move industry to tighter semantics should we engineer around mistake?
[12:44:03] <ggm> Mark semantics are ironclad
[12:44:32] <leifj> and remember that the driving force here is spam reduction - that makes for a powerful motivation for both vendors and deployers
[12:44:39] <ggm> Mark because of urgency of problem this is not pure arch. have to take practicalities into account
[12:44:53] <leifj> M$ have been know to issue hotfixes
[12:44:56] <ggm> Andrew. same arg used years ago with HELO checks being ignored
[12:44:58] <rpayn422> '18
[12:45:04] <ggm> expediency arguments being repeated
[12:45:40] <ggm> so because 1in 10 MTAs are broken we're walking away from the clean solution
[12:45:40] <jakob> I fail to see why the MTA cannot do it own DNS lookups if the API on the OS doesn't support this. OpenSSH on windows already does this for unknown types (SSHFP lookups)
[12:45:41] <ggm> MArk yes.
[12:46:01] <ggm> Andrew so you believe that you'll have 80% uptake, the 20% will be significant,
[12:46:05] --- rpayn422 has left: Logged out
[12:46:07] <ggm> Mark yes.
[12:46:09] <wrs1864> jakob: this was discussed at the interim meeting and on the mailing list
[12:46:17] <jakob> ack
[12:46:19] <leifj> jakob - right
[12:46:25] <wrs1864> the MS firewalls block UDP/TCP 53
[12:46:34] <wrs1864> you *must* use their RPC API
[12:46:39] <paf> But not TCP/25?
[12:46:50] <ggm> Andrew, but its his argument: he's talking about a number of MTAs, number getting smaller, making a compromise for small number of machines. believe its unwise.
[12:46:59] <leifj> ouch
[12:47:20] <ggm> Mark ok. not just MS machines. experience in wild, shows extremely old resolver code is deployed. linux distros with 15yo resolvers in them. [nods]
[12:47:57] <ggm> Joe Halprin require recs to do SRV. stuff in XMPP.
[12:48:16] <ggm> if they dont support SRV, how to get other stuff in. makes sense to have fallback. dont have to like it.
[12:48:17] <mrose> joe hildebrand
[12:48:17] <resnick> Joe Hildebrand
[12:48:27] <ggm> [sorry =ggm]
[12:48:56] <ggm> Mike fragmentation is lousy transport mechanism. multiple recs, blow out MTU, no other recourse, or use TCP, that is a problem. harmful to net.
[12:48:59] <Shevek> Didn't we talk about MTU a few minutes, weeks, hours and years ago?
[12:49:10] <ggm> Mark avg. recsize is shown to permit 2 before blowing MTU
[12:49:12] <Shevek> I think my recording is looping.
[12:49:13] <wrs1864> yes
[12:49:15] <ggm> Mike but its unbounded
[12:49:28] <ggm> Mark but prefixes woul help ?
[12:49:30] <ggm> Mike yes
[12:49:57] <ggm> Doug Otis. regarding what might break. is requirement for no more than 10 calls be required to be impl. but DNS queries per calls is dozens
[12:50:03] <ggm> Mark dont think dozens
[12:50:15] <ggm> Doug could easily be dozens. even more queries impl.
[12:50:28] <ggm> Mark thats wrong, what we've discussed here, only one selected for processing.
[12:50:30] <mengwong> doesn't this go back to "this decision was a compromise"?
[12:51:04] <ggm> Doug, until you find the one you're looking for. looking at number of DNS queries, spam stream is 4kb. take a few UDP queries obligated to run, exceed this traffic
[12:51:10] <ggm> Mark concern about spammer or good mail
[12:51:41] <mengwong> PHB is now going to agree with Doug Otis that exists and macros are unnecessary complexities and should be removed from a future version.
[12:51:42] <ggm> Doug, no, can't make that assertion about knowing sizes. dont know about DNS poisoning, who knows whats going to happen. list can grow very long whats in recs. have to take close look at what the limits are
[12:51:46] <Shevek> Tell whoever this is that spam isn't about reducing network traffic. It's about reducing human time used for deleting it.
[12:52:09] <ggm> Doug cant say this is the endpoint. its the beginning of the game. number of DNS Q is indeterminate.
[12:52:19] <ggm> Mark your concern is the number of Q can be large, unbounded. Noted.
[12:52:40] <ggm> PHB. thought experiment. what pure arch would mean. we'd burn all RFCs and shred the drives
[12:52:43] <ggm> Mark keep on topic.
[12:53:16] <ggm> PHB every decision is made against existing spec and deployed arch. we're trying to propagate stuff. two issues. one is MARID, the other is DNSEXT. both important.
[12:54:06] <ggm> Ted hardies compromise gets everyone what they want. MARID propagates. Vendors have to go fix DNS. to support DNSEXT. so, DNSEXT pulled along in wake of MARID even if not going to use other RR. will pull it along. thats what people should want. propagation. pure architecture is lala land
[12:54:16] <ggm> Dave Crocker. want to go down this path of tradeoffs.
[12:54:16] --- hta has left: Disconnected
[12:54:48] <ggm> First Q is, have tradeoffs as WG, considered them at length, made compromise choice, thats process. some people dont like it (vocally) but nobody likes, it, we're choosing
[12:54:59] <ggm> the least suckful, mitigate the suckery, but it still sucks
[12:55:03] <ggm> second point
[12:55:39] <ggm> easilty rough consensus, that the clean solution is RR. its part of the consideration. so the second half is about adoption risk, which must dictate or dominate in this world its an engineering group.
[12:56:24] <ggm> the issue of new records is not new, had it for a long time. had DNS group assurances for a long time. as noted SRV, gained excellent adoption, but have problems. when can be used, makes itinto specs. this set of recs doesnt appear to be ameanable to that, so have to use TXT.
[12:56:50] <ggm> issues with TXT well understood. but do we put a high risk., certainty of problem to deploy, (RR) or do we put a choice in with a scaling problem if it succeeds (TXT)
[12:57:00] --- peterd has left
[12:57:15] <ggm> putting on machiavellian hat, wont fix DNSEXT rr problem until critical mass. this happens post-hoc. if we happen to be the ones who make that problem it WILL be fixed.
[12:57:21] --- hta has joined
[12:57:32] <mengwong> Jim Lyon notes Dave Crocker lovefest event
[12:57:36] <ggm> Jim I agree with Dave, and since thats so rare I thought I'd stand up and say it. [laughter]
[12:57:41] <ggm> Dave this is an emerging pattern
[12:58:18] <ggm> Olaf Kolkman. we started with versioning, if we take out versioning and say next version will be in RRtype, next version is forced in, gives people chance to upgrade dns server inf. put it into the arch, to move to RRtype later
[12:58:20] --- johani has joined
[12:58:28] <ggm> Mark feel bad about future constraint.
[12:58:35] <ggm> Andy is that what you meant?
[12:58:51] <ggm> Olaf, restricting use of current spec to one version. leave open to future, obvious way is RR
[12:58:56] <ggm> Mark to some extend spec does speak to that issue
[12:59:13] <ggm> Mark one reason why minor number not in (but will put it in)
[12:59:22] <ggm> send email
[12:59:32] <ggm> Andrew Dunhill (not Donaghue)
[13:00:14] <ggm> find args for compromise compelling. but its incumbent for us to go to the operational community to get better information about this compromise, like to ask this group to do so. its a key compromise.
[13:00:21] <ggm> Mark people are represented
[13:00:31] --- edmundo.cazarez has left
[13:00:42] <ggm> Marshall historical note, we got DNS expert at early meeting
[13:01:08] <ggm> [btw, I had to ask MS to change DNS to do ip6.arpa. it took about 2 years to make it into release, and I suspect not because of my intervention directly. but maybe it helped -ggm]
[13:01:21] <ggm> Mike. we'll polish. spruice up.
[13:01:32] <ggm> play well in the net as-is. play well with other tools
[13:01:58] <AndrewD> My name is Andrew Donoho - not Dunhill not Donaghue, Thanks.
[13:02:07] <ggm> Mark we all agree we're sick
[13:02:22] --- jis has left: Disconnected
[13:02:24] <ggm> [sorry. ]
[13:02:41] <ggm> Mark converged.
[13:03:56] <ggm> Doug Otis. regarding prefixes. looking at wildcarding. will be exploited by spammers if open, gives free hand. none of this will be cached. other recs can supplant wildcards, have to go back to DNS server.
[13:03:56] <ggm> Mark not client side. never seeds the wildcard.
[13:03:58] <ggm> Doug can cache the instance of the name, but random subdomains will fill cache.
[13:03:59] <ggm> Mark DoS attacks discussed in draft.
[13:04:17] --- edmundo.cazarez has joined
[13:04:24] <ggm> Was investigated, while possible, more difficult than several other well known attacks, not a new or worse attack than today. no incentive.
[13:04:53] <ggm> Doug made no mention of that. its an exploit. can exploit that record to get past filtering. flood DNS cache. not describing DoS, but outcome of using record type, allow free reign of service.
[13:05:04] <ggm> Mark isnt that same as wildcard in any protocol.
[13:05:21] <ggm> Doug these are permissions. different class of record.
[13:05:29] <ggm> Jukka<?> dont understand how it gets round filtering
[13:05:51] <ggm> Doug throw in several dozen fakes, makes task more difficult. throws wrench into normal methods
[13:05:56] <ggm> Mark sounds like same as other
[13:06:08] <mengwong> i think doug's point is that a domain might say "v=spf1 ?all" and a spammer might exploit that.
[13:06:19] <ggm> Roy Arendts/ cache/DoS. standard ops, for operating caching resolver is to not have it open to world.
[13:06:29] <mengwong> my answer is (1) if that becomes a problem, the domain should not do that, and (2) that's no worse than the current internet.
[13:07:22] <ggm> Jim Fenton. little in conflict with myself here. if using TXT, distinguishing prefix is good. otoh, breaking wildcard behaviour, don't understand all args, will adding prefix to domain name. would that require I publish SPF recs for every host that I used as domain part of address?
[13:07:29] <ggm> Mark step back from wildcard.
[13:07:59] <ggm> if you have example.com, hosts, some MTA some not. concerned with names being used in mail contexts, then goal is to publish recs for every name, for names really
[13:08:08] --- leifj has left: Disconnected
[13:08:11] <ggm> want to use, will have recs to allow, and for all the others, minus-all rec.
[13:08:19] <ggm> (to prevent it, in context of PRA in email)
[13:08:43] <ggm> if joe sysadmin, may think 'publish wildcard as minus-all, then do specifics to allow'
[13:09:03] <ggm> if there is a _marid_<x>.example.com then this scheme works, there are no recs with the full name
[13:09:14] <yakovsh> (wasn't there an issue with _?)
[13:10:00] <mengwong> only in people's prejudices
[13:10:12] <ggm> if we don't use a prefix, and look up the TXT for machinea.example.com then the wildcard doesnt work. because if B has other TXT, wildcard wont apply so wont be seen to block. but if you DO have a prefix, then it will have no other TXT so then wildcard WILL return. wildcard works.
[13:10:13] <mitsubachi> yakovsh: there are implementation issues in some places, the RFC says it's okay to use
[13:10:42] <ggm> Jim Fenton but if using prefixes, looking up _marid.*.example.com.
[13:11:01] <ggm> Mark can't publish that. but publish TXT on *.marid.com its used.
[13:11:08] <yakovsh> mistabuchi: i was refering to the implemention issues, i remember reading something on the spf list about that
[13:11:11] <ggm> Andy thats sams point. can be done differently
[13:11:38] --- JohnThielens has joined
[13:11:38] <ggm> PHB depends
[13:12:08] <ggm> [mark is gabbling. I can't type this]
[13:12:23] <mitsubachi> I think the answer is no
[13:12:46] <Shevek> publish marid at *.example.com publish A at host.example.com. query marid at _marid.host.example.com. Do you get the record.
[13:12:47] <mitsubachi> if the marker is _marid_hostb.example.com it will be in there
[13:12:47] <ggm> asking about clarification on how wildcards happen. consensus they are blocked
[13:12:57] --- gih has left
[13:13:02] <mitsubachi> if the marker is _mard.hostb.example.com you will not get it
[13:13:14] <ggm> Mark are we all in agreement they don't matter? [consensus]
[13:13:37] <ggm> Ted gives Mark applause for managing his first IETF [applause]
[13:13:45] <ggm> Andy Newton any more comments?
[13:13:55] <ggm> on protocol draft, not on this issue
[13:13:58] --- DouglasOtis has left: Disconnected
[13:14:00] --- SAH has left
[13:14:10] <ggm> ajourn. see everyone back here for the afternoon session. Grande C
[13:14:12] <Shevek> phew
[13:14:15] <wrs1864> I would like to raise the issue of using the SOA check
[13:14:17] <ggm> 3:30
[13:14:19] <wrs1864> uh, nevermind
[13:14:23] --- peter has left: Disconnected
[13:14:24] --- ogud has left
[13:14:25] <ggm> god. I'm wiped.
[13:14:25] <mengwong> mmph
[13:14:28] <yakovsh> sounds like a fun session
[13:14:30] <mengwong> thanks for typing, ggm.
[13:14:33] <mengwong> come see me and i will give you a chocolate.
[13:14:37] <wrs1864> yes, thanks ggm!
[13:14:40] <mengwong> =)
[13:14:41] <resnick> Well done ggm!!
[13:14:44] <mitsubachi> ggm, thanks!
[13:14:47] <ggm> thanks for the help with names people! I'm clueless with spelling donaghughehaughtonstonefetherliegh
[13:14:53] <galvinjamesm> Thanks to the scribes!
[13:14:54] --- jakob has left: Disconnected
[13:15:06] --- aen has left
[13:15:08] --- resnick has left: Disconnected
[13:15:10] --- fenton has left
[13:15:11] --- galvinjamesm has left
[13:15:12] --- pawal has left: Logged out
[13:15:45] --- yakovsh has left
[13:15:47] --- orange has left
[13:16:00] --- marcos.sanz has left
[13:16:13] --- yone has left
[13:16:30] --- paf has left: Disconnected
[13:16:34] --- mtnviewmark has left: Disconnected
[13:16:57] --- edmundo.cazarez has left
[13:16:58] --- dblacka has left: Disconnected
[13:17:01] --- JohnThielens has left
[13:17:21] --- johani has left
[13:18:03] --- suz-isc has left
[13:18:18] --- mengwong has left: Disconnected
[13:18:57] --- hildjj has left: Disconnected
[13:18:58] --- andy has left: Disconnected
[13:19:36] --- jakob has joined
[13:19:37] --- jakob has left: Lost connection
[13:19:52] --- mrose has left
[13:20:58] --- hardie has left: Disconnected
[13:22:09] --- kmurchison has left
[13:22:37] --- andy has joined
[13:22:58] --- andy has left: Disconnected
[13:25:36] --- leg has left: Disconnected
[13:27:44] --- hta has left
[13:29:25] --- ohm has left: Replaced by new connection
[13:29:26] --- ohm has joined
[13:29:46] --- tonyhansen has left: Replaced by new connection
[13:32:44] --- amelnikov has left: Replaced by new connection
[13:32:44] --- amelnikov has joined
[13:32:44] --- amelnikov has left
[13:33:01] --- yushun has left: Disconnected
[13:33:06] --- vlevigneron has left: Disconnected
[13:34:41] --- AndrewD has left: Disconnected
[13:34:50] --- dcrocker has left: Disconnected
[13:38:03] --- hadmut has left
[13:39:17] --- andreas-b has left
[13:40:25] --- RandyG has left: Disconnected
[13:42:46] --- ggm has left: Disconnected
[13:43:38] --- SamSilberman has left: Disconnected
[14:02:36] --- hadmut has joined
[14:08:34] --- paf has joined
[14:12:50] --- paf has left: Disconnected
[14:16:24] --- peter has joined
[14:16:52] --- peter has left: Disconnected
[14:17:10] --- peter has joined
[14:33:49] --- peter has left
[14:35:47] --- SamSilberman has joined
[14:38:22] --- leg has joined
[14:42:25] --- paf has joined
[14:47:25] --- ohm has left: Replaced by new connection
[14:47:26] --- ohm has joined
[14:47:55] --- dcrocker has joined
[14:48:13] --- dblacka has joined
[14:48:57] --- yakovsh has joined
[14:48:58] --- dblacka has left
[14:51:40] --- vlevigneron has joined
[14:52:09] --- ogud has joined
[14:52:10] --- leg has left
[15:06:20] --- vlevigneron has left
[15:13:25] --- gih has joined
[15:18:05] --- yakovsh has left
[15:25:39] --- mengwong has joined
[15:31:42] --- jimwagz has joined
[15:41:12] --- gih has left
[15:48:57] --- dcrocker has left: Disconnected
[15:59:50] --- mitsubachi has left
[16:00:23] --- mitsubachi has joined
[16:05:40] --- hadmut has left
[16:07:47] --- resnick has joined
[16:11:03] --- mengwong has left: Disconnected
[16:12:47] --- mengwong has joined
[16:21:34] --- DouglasOtis has joined
[16:22:24] --- DouglasOtis has left
[16:30:20] --- jimwagz has left
[16:32:01] --- eric_allman has joined
[16:32:10] --- hildjj has joined
[16:32:50] --- psa has joined
[16:36:42] --- hildjj has left
[16:38:30] --- bruce2 has joined
[16:38:32] --- bruce2 has left: Disconnected
[16:45:12] --- mengwong has left: Disconnected
[16:52:41] --- mengwong has joined
[16:53:04] --- SamSilberman has left: Disconnected
[16:55:49] --- galvinjamesm has joined
[16:55:58] <mengwong> we're in Grande C, btw
[16:56:07] <psa> indeed
[16:56:11] <psa> be there or be square!
[16:56:20] <galvinjamesm> does listening count?
[16:56:53] <psa> if ggm scribes again, I think we need to buy him a drink
[16:57:09] <wrs1864> I can't hear a thing
[16:57:11] <resnick> I think he'll need more than one.
[16:57:33] <psa> wrs1864: we have not started yet
[16:57:34] <wrs1864> can someone test the mic ?
[16:57:42] <psa> T - 20 minutes
[16:57:46] <wrs1864> yeah, but on ch2, I could hear lots of stuff
[16:57:54] <galvinjamesm> I can hear the room. the audio feed is greate
[16:58:08] <galvinjamesm> I can hear you!!
[16:58:11] <resnick> St. Peter just spoke into the mics.
[16:58:13] <wrs1864> hi
[16:58:13] <galvinjamesm> test test
[16:58:19] <galvinjamesm> test again
[16:58:20] <wrs1864> yeah, that was good
[16:58:23] <psa> super
[16:58:26] <wrs1864> thanks
[16:58:33] <psa> i did not test the WG Chair mics
[16:58:49] <psa> that's a restricted area, after all ;-)
[16:58:50] <galvinjamesm> As soon as Marshall puts his music up we'll know for usre.
[16:58:51] <wrs1864> I was listening to ch4 yesterday during the tail end of the ASRG meeting, and I couldn't hear much
[16:58:52] <resnick> People are still eating their brownies. Go get a cookie before we start.
[16:59:03] <wrs1864> maybe they just didn't use the mics very much
[16:59:17] <mengwong> can you listen to the grande c channel?
[16:59:22] <mengwong> mark is chatting with jutta.
[16:59:59] <galvinjamesm> mw: yes, listening to grand c.
[17:00:21] --- pawal has joined
[17:00:27] <wrs1864> I can't hear what mark and jutta are saying, but I can faintly hear people talking.
[17:00:30] --- hadmut has joined
[17:00:48] <psa> wrs1864: it's a subdued crowd here :-)
[17:01:07] <wrs1864> oh
[17:01:09] <psa> or subdude as the case may be
[17:01:13] <wrs1864> wait until the folks from DNSOP show up.
[17:01:26] <psa> shyeah
[17:01:30] <wrs1864> someone asked for more participation in the MARID meeting
[17:01:36] <mengwong> ?
[17:01:39] <psa> be careful what you wish for...
[17:01:39] --- hkruse has joined
[17:01:44] <wrs1864> and when MARID was mentioned, the DNSOPs folks hissed
[17:01:52] <psa> hrm
[17:01:55] <psa> that's not helpful
[17:02:09] <pawal> avoid talk of TXT records :)
[17:02:10] --- ogud has left: Lost connection
[17:02:12] <wrs1864> probably to be expect though
[17:02:16] <wrs1864> yeah
[17:03:24] --- yakovsh has joined
[17:03:40] <psa> that was a test at the WG Chair table
[17:03:42] <galvinjamesm> I heard testing
[17:04:08] <galvinjamesm> and more testing
[17:06:17] --- kjd has joined
[17:09:02] --- mrose has joined
[17:09:18] --- hkruse has left
[17:09:28] --- peterd has joined
[17:10:37] --- hkruse has joined
[17:11:05] * wrs1864 waits for Marshall to start playing music...
[17:11:28] --- rpayne has joined
[17:11:34] --- orange has joined
[17:11:34] <galvinjamesm> (L) :cool (8)
[17:11:57] --- stpeter has joined
[17:12:24] --- mitsubachi has left
[17:12:28] <mengwong> mrose just played some music.
[17:12:34] <mrose> happy?
[17:13:47] <galvinjamesm> :p
[17:15:01] --- edmundo.cazarez has joined
[17:15:17] --- jakob has joined
[17:15:19] --- hp has joined
[17:16:22] --- mtnviewmark has joined
[17:16:31] --- RandyG has joined
[17:16:35] --- SamSilberman has joined
[17:17:09] --- SAH has joined
[17:17:14] --- qpathname has joined
[17:17:29] --- Suresh Krishnan has joined
[17:17:34] --- ogud has joined
[17:17:59] <qpathname> Hello everyone. Daniel Quinlan (IronPort, SpamAssassin) here
[17:18:11] <psa> greetings
[17:18:19] <psa> thanks for SA
[17:18:25] --- ogud has left
[17:18:33] <qpathname> you're welcome :-)
[17:18:37] --- dblacka has joined
[17:18:43] --- AndrewD has joined
[17:18:57] <wrs1864> I just got a false positive with SA 2.63!
[17:18:58] --- yone has joined
[17:19:05] <wrs1864> first one in geez, a couple of months.
[17:19:08] --- DouglasOtis has joined
[17:19:13] <psa> <-- http://www.jabber.org/people/stpeter.php but I'm using a stealth account right now :-
[17:19:15] <wrs1864> so, THANKS! SA is great!
[17:19:26] --- tonyhansen has joined
[17:19:30] <qpathname> SA-related discussion to irc.freenode.net #spamassassin ;-)
[17:19:32] --- aen has joined
[17:19:48] * psa shall scribe
[17:19:50] <galvinjamesm> Thanks to the scribe!
[17:19:57] <wrs1864> ditto
[17:19:59] <psa> I won't be as good as ggm
[17:20:01] --- ogud has joined
[17:20:04] <psa> agenda
[17:20:07] <psa> IPR
[17:20:15] <psa> review and discuss marid-core
[17:20:21] <psa> milestones for CSV
[17:20:25] <psa> IRP
[17:20:29] <psa> IPR
[17:20:37] <psa> what parts of sender-id are covered by IPR claims?
[17:21:03] <psa> are the terms for licensing the IRP acceptable?
[17:21:09] <psa> are there any trademark issues?
[17:21:18] <psa> Harry Katz...
[17:21:22] <yakovsh> which channel btw?
[17:21:27] <wrs1864> ch 4
[17:21:27] <yakovsh> 4 got it
[17:21:36] <qpathname> psa: the licensing for Sender-ID from Microsoft is RF, but incompatible with pretty much all open source.
[17:21:41] <psa> what parts covered
[17:21:44] --- RandyG has left: Logged out
[17:21:50] --- RandyG has joined
[17:21:54] --- marka-isc has joined
[17:21:58] <psa> MS has IPR claims on draft-marid-core-02
[17:22:06] --- warlord has joined
[17:22:17] --- marcos.sanz has joined
[17:22:36] <psa> mic adjustments
[17:22:49] <psa> IPR claims disclosed on IETF disclosure web page
[17:22:53] <psa> got URL?
[17:22:57] --- vlevigneron has joined
[17:23:09] <psa> he cannot speak to any other claims, only MS claims
[17:23:28] <yakovsh> its not on the page
[17:23:41] <yakovsh> http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt is the only one there right now
[17:23:46] <wrs1864> yes, that is the one
[17:23:47] <psa> claims to caller-ID -- revision needs to be made thereto
[17:23:49] <psa> yes
[17:23:56] <yakovsh> any idea what the exact claims are?
[17:24:13] <yakovsh> with all the prior art...
[17:24:21] <wrs1864> no
[17:24:22] <resnick> My belief is it's the PRA algorithm.
[17:24:23] <psa> there have been concerns expressed about the license
[17:24:25] --- danwing has joined
[17:24:36] <yakovsh> resnick: isn't this algorithm present in some other drafts?
[17:24:38] --- ogud has left
[17:24:45] <psa> gather further concerns today
[17:24:48] --- sakai has joined
[17:24:52] <qpathname> psa: some of the claims are "patents are coming" non-specific
[17:25:00] <psa> TM issues: company in UK has filed TM on term Sender ID
[17:25:14] <qpathname> where is the audio feed?
[17:25:15] <psa> MS attorneys believe that any application will not withstand scrutiny (too common)
[17:25:18] <resnick> yakovsh: I didn't say they were legit claims; only that I believe that's what they're talking about.
[17:25:20] <wrs1864> ch 4
[17:25:30] <wrs1864> http://videolab.uoregon.edu/events/ietf/ietf60.html
[17:25:31] <psa> open the floor
[17:25:33] <yakovsh> CHANNEL 4
[17:25:36] <psa> Ted Hardie at the mic
[17:25:50] <psa> can describe claims in more detail?
[17:25:55] <wrs1864> who?
[17:26:04] <psa> algorithm, or basic method of storage
[17:26:19] <psa> HK: apply only to marid-core
[17:26:28] <yakovsh> can someone channel a question?
[17:26:34] <resnick> Martin Dürst.
[17:26:46] <resnick> yakovsh: Go ahead.
[17:26:58] <psa> Martin Duerst: can we have URL?
[17:27:06] <psa> URL is wrong?
[17:27:13] --- andreas-b has joined
[17:27:25] <psa> URL provided in this room is correct
[17:27:37] <yakovsh> recnick: what about all other drafts such as rmx, spf, paul vixie's draft (2001), dmp, mta mark, etc. in regards to prior art? is microsoft claiming something that is not present in these drafts?
[17:28:00] <mengwong> Hadmut Danisch, author of RMX
[17:28:17] <psa> HD: concern about worldwide use
[17:28:25] <psa> claims only under American law?
[17:28:30] --- kjd has left: Replaced by new connection
[17:28:39] <mengwong> Jim Lyon, MS
[17:28:52] <psa> JL: no patent rights, applications only
[17:29:00] <psa> filed in U.S., not sure where else filed
[17:29:13] --- JohnThielens has joined
[17:29:27] <psa> William Empson (?): why not issued FAQ before this meeting?
[17:29:30] --- corby has joined
[17:29:32] <mengwong> william@elan.net.
[17:29:37] --- corby has left
[17:29:37] --- kjd has joined
[17:29:54] <psa> was supposed to have been issued two days prior to meeting
[17:29:55] --- ogud has joined
[17:30:05] --- corby has joined
[17:30:15] <psa> HK: multiple teams of lawyers working on this, and have been discussion with people on and off list about the concerns
[17:30:33] <psa> s/been/been in/
[17:30:54] <psa> William: do claims apply to any other proposals?
[17:31:11] <psa> HK: IPR claims (patent application) on draft-ietf-marid-core-02 only
[17:31:18] <resnick> yakovsh: Did that answer your question?
[17:31:59] --- leg has joined
[17:32:10] <psa> William: would splitting the document help? concern about IPR claims on core protocol
[17:32:16] <yakovsh> resnick: half-way
[17:32:28] <psa> information about how to choose submitter value would be useful by itself (not only for MARID)
[17:32:41] <resnick> psa: It's William Leibzon
[17:32:48] <psa> resnick: thanks
[17:32:55] <resnick> yakovsh: You want me to ask something else?
[17:32:55] <yakovsh> resnick: i am wondering whether specifically all information in spf, rmx, dmp, etc. is excplietly not under the ipr claims
[17:33:10] <yakovsh> resnick: or whether any of this is serving as prior art
[17:33:22] <gconnor> (question to anyone who knows, what's the best way to hear audio on a fedora core 2 box? msg me privately if you know...)
[17:33:48] <psa> WL: marid-core has PRA algorithm and also information about goals of MARID etc.
[17:34:00] --- ogud has left
[17:34:23] <psa> Dave Crocker: core of PRA work is clarification of RFC 2822 and is useful on an independent basis
[17:34:45] <psa> DC: this information is spread in multiple specs and is very helpful to put it in one place
[17:34:51] <psa> DC: absolutely should be in one document
[17:35:07] <psa> DC: this work has value for things other than MARID
[17:35:09] --- ogud has joined
[17:35:13] <mengwong> pete resnick channelling one of youse now.
[17:35:28] <wrs1864> am I confused? Isn't marid-core just the PRA stuff now a days?
[17:35:34] --- sakai has left
[17:35:43] <yakovsh> thanx
[17:35:47] <yakovsh> i heard that
[17:35:52] <yakovsh> very vague
[17:35:53] --- rand@sendmail.com has joined
[17:35:58] <psa> channelled question: i am wondering whether specifically all information in spf, rmx, dmp, etc. is excplietly not under the ipr claims or whether any of this is serving as prior art
[17:36:02] <psa> HK: no idea
[17:36:14] <resnick> I kinda thought that would be the answer, but it was probably worth asking.
[17:36:18] <yakovsh> resnick: thanks
[17:36:27] <psa> DC: critical issues can linger if we have IPR problems, which will delay solutions
[17:36:45] <yakovsh> resnick: its on record now
[17:37:27] <psa> DC: we need this issue from pending to resolved; what will it take to resolve this and when?
[17:37:52] <psa> HK: we're working hard
[17:38:04] <psa> DC: I know how lawyers work, so obviously this is not their top priority
[17:38:10] --- sakai has joined
[17:38:17] <psa> DC: WG propose a deadline, if not met, we move on
[17:38:39] <psa> Chairs note the suggestion and will address at end of this section of the discussion
[17:38:40] <mengwong> Doug Otis, MAPS, asks...
[17:39:05] <mengwong> Margaret Olson, constant contact / ESPC, comments:...
[17:39:16] <gconnor> If people are taking questions from the jabber session, could some one please ask: when should we as a group decide to drop MS property from proposal if not resolved? When is the Real drop dead date?
[17:39:22] --- Suresh Krishnan has left
[17:39:31] <psa> Margaret Olson: do we think MS would hold up a spam solution because of IPR?
[17:39:32] <qpathname> someone want to ask this for me? "I (Daniel Quinlan) have a question for Harry/MS: I'm part of one of those groups your lawyers have been working with, is there anything we and our respective companies can do to speed along the MS process?"
[17:39:40] <psa> I missed Doug's question, sorry
[17:39:40] <resnick> gconner: Marshall said: This will be answered at the end of the session.
[17:39:41] <yakovsh> gconnor: it sounds like the chairs will address it later
[17:39:49] <gconnor> ok
[17:39:52] <mrose> gpathname - i'll ask in a moment.
[17:40:01] <resnick> Doug asked: Is it just the PRA algorithm that is at issue?
[17:40:02] <mengwong> qpathname: setting a deadline will probably help speed the process. i don't know if HK is going to be able to answer that.
[17:40:08] <yakovsh> mrose: same from me as a former asrg chair
[17:40:16] <yakovsh> mrose: anything if i can provide to help
[17:40:26] --- leslie has joined
[17:40:26] <qpathname> resnick: I think it's a big unknown because there could be other patents coming, not just from MS
[17:40:35] <psa> M.O.: pressure from MS customers will have a natural tendency will lead them to solve the problem
[17:40:59] <mrose> your question has been asked.
[17:41:11] <qpathname> thanks (I heard)
[17:41:23] <mengwong> Phillip Hallam-Baker, Verisign, comments...
[17:41:24] <psa> HK: we're working on this as quickly as we can
[17:41:25] <qpathname> we will certainly keep pinging :-)
[17:41:30] <mrose> gpathname - thanks!
[17:41:42] <psa> PHB: concerned about precedent
[17:41:48] <psa> mengwong: thanks
[17:42:00] <psa> Ted Hardie...
[17:42:11] <psa> TH: thanks for professionalism
[17:42:27] --- malamud has joined
[17:42:31] --- jis has joined
[17:42:32] <psa> TH: work of WG is to balance engineering with IPR and license
[17:42:50] <qpathname> I think I agree with PH-B: dropping PRA would be bad in terms of fixing the license and helping the MS people working to fix this ... fix this
[17:42:56] --- andy has joined
[17:43:02] <DouglasOtis> What is their IP? Does this include the PRA? Answer, Yes.
[17:43:12] <yakovsh> i would add to TH, anything that is not deriable from all other previous drafts as well
[17:43:20] <psa> TH: if there is something in PRA that is not derivable from 2822's statement about email injection, we could consider saying that the algorithm we are using is injection
[17:43:27] <hadmut> What exactly does 'PRA' stand for?
[17:43:27] <psa> TH: this may eliminate one of the issues
[17:43:37] <mengwong> Purported Responsible Address
[17:43:42] --- corby has left
[17:43:43] <psa> hadmut: Press Release Algorithm?
[17:43:45] <hadmut> thanks
[17:44:03] <psa> WG could consider using injection algorithm and then moving to PRA
[17:44:08] <psa> TH: license....
[17:44:32] <psa> TH: the license is royalty-free and therefore in line with existing IETF preference
[17:44:54] <psa> TH: concern is need to submit intent to use license
[17:44:58] <gconnor> does anyone know what "injection algorithm" is? is this a reference to another rfc?
[17:45:16] <psa> TH: license could be granted based on inclusion of the text alone, rather than need to register or submit intent with MS?
[17:45:24] --- hp has left
[17:45:25] <psa> gconnor: RFC 2822
[17:45:27] <mtnviewmark> it is part of RFC 2822 - it is mentioned in the section on "Resent-*" headers
[17:46:09] <qpathname> I think the thing that needs to be pointed out here is that there are more issues with the license than notification to MS.
[17:46:17] <psa> Pete Resnick....
[17:46:34] <psa> RPR: I could write up a summary of what I understand to be the semantics of injection
[17:46:40] <psa> s/RPR/PR/
[17:46:49] --- corby has joined
[17:46:49] <wrs1864> Uh, but what about the requirement to add a term to the license? No one is going to add a term to the GPL
[17:47:03] <psa> PR: would this be useful input to the process?
[17:47:04] <qpathname> wrs1864: and no one can
[17:47:05] --- hp has joined
[17:47:18] <pawal> the word "inject" or "injection" is not present in 2822...
[17:47:36] <gconnor> < snide > Sure it would be useful, but don't forget to mark it "patent pending" </snide>
[17:47:40] <psa> any other questions about IPR matters?
[17:47:45] <mengwong> Rand Wacker from Sendmail...
[17:48:14] <psa> RW: we have been working with MS to come up with something that is compatible with our open-source license
[17:48:30] <psa> RW: what are the terms of the license?
[17:48:32] --- kjd has left: Replaced by new connection
[17:48:43] <wrs1864> can someone channel a question: Will the IPR license be compatible with the GPL?
[17:48:46] <psa> TH: we need to need to know how engineering and IPR fit together
[17:49:06] <psa> TH: we need to answer the engineering questions first
[17:49:11] --- kjd has joined
[17:49:22] --- fenton has joined
[17:49:37] <psa> TH: only one algorithm in marid-core, or everything in marid-core?
[17:49:57] <psa> (which algorithm may be derived from semantics of injection in RFC 2822)
[17:50:07] <qpathname> wrs1864: it's more than GPL compatibility really
[17:50:11] <psa> TH: so critical to understand this first
[17:50:24] <wrs1864> qpathname: agreed, but that is a big start
[17:51:33] <psa> Andy Newton: do you believe that the bit of engineering is only on a specific set of steps in marid-core, or something more broad?
[17:51:45] <qpathname> (1) non-transferable, not sublicensable, privity of contact (2) adding notice to license (3) limited to "compliant" implementations plus some other minor quibbles
[17:51:50] <psa> Doug: question about scope of use
[17:52:03] <psa> DO: limits scope to Sender-ID specifically?
[17:52:21] --- hardie has joined
[17:52:22] <qpathname> DO: excellent point
[17:52:24] <mengwong> Mark Lentczner follows up to Ted.
[17:52:36] <gconnor> Question, if someone would relay: Greg Connor asks online, has MS considered just throwing this property open to the public domain, and not worrying about defensive license? If it's offered with no restriction, but also no warranty, who is likely to sue MS over it?
[17:52:52] <psa> Mark: followup to Ted: what license are current MTAs published under? this would help us understand what kinds of licenses we would need to seek compatibility with
[17:53:00] --- mlshore has joined
[17:53:03] <mengwong> Rand Wacker from Sendmail responds...
[17:53:10] <mrose> gconnor - i will ask
[17:53:31] --- admcd has joined
[17:53:32] <psa> Rand: we have hybrid OS/commercial license (OSI-approved)
[17:53:39] --- corby has left
[17:53:46] --- hp has left: Disconnected
[17:54:02] <mrose> your question has been asked
[17:54:03] <gconnor> (Sure would be a gesture of goodwill if they decide to just donate IPR free and clear with no restriction)
[17:54:10] <gconnor> ok thnx mrose
[17:54:10] <psa> HK : was considered and rejected
[17:54:13] <yakovsh> why?
[17:54:30] <psa> HK: defensive aspects are important to MS
[17:54:42] <yakovsh> what about assigning it to a third party?
[17:54:44] <wrs1864> can someone channel a question: Will the IPR license be compatible with the GPL? (or is out of scope?)
[17:54:57] <mengwong> John Levine, author of book on qmail, comments:
[17:55:00] <psa> John Levine: qmail has bizarrre license
[17:55:03] --- hp has joined
[17:55:23] <psa> need to submit patches separately etc. -- qmail is not modifiable, but patches have wide variety of licenses
[17:55:49] <mrose> wrs1864 - i will ask
[17:55:55] <yakovsh> can someone channel a question: has microsoft considered assigning the patent to a third party such as a non-profit, or an industry organization (not necessarily the ietf)?
[17:56:05] --- Corby has joined
[17:56:06] <mrose> yakovsh - i will ask
[17:56:11] <psa> John: w.r.t. PRA, patent office has no experts on email, so they may grant patent even though it is derivative from RFC 2822
[17:56:11] <yakovsh> thanx
[17:56:52] <mrose> wrs1864 - your question has been asked
[17:56:54] <wrs1864> (wrs1864 == wayne schlitt)
[17:56:57] <wrs1864> thanks marshall
[17:57:05] <psa> psa-as-non-scribe wonders what the intent of the patent application is -- is it to protect MS, protect the community/network, or something else?
[17:57:11] --- NFreed has joined
[17:57:17] <psa> WK: to prophesize about the future would be difficult
[17:57:18] <yakovsh> psa: same here
[17:57:24] <resnick> psa: I believe it is a defensive patent:
[17:57:31] <qpathname> Question, if someone could state it, Daniel Quinlan: "Given the long history of development and prior art, the large number of companies developing Sender-ID implementations, wouldn't it be prudent to provide equal protect to everyone, not just MS?"
[17:57:42] <mrose> yakovsh - your question has been asked
[17:57:50] <yakovsh> thanx
[17:57:56] --- leifj has joined
[17:57:57] <qpathname> s/equal protect/equal protection/
[17:57:59] <resnick> A lever such that anyone who implements PRA won't be able to sue MS.
[17:58:21] <psa> mrose channels question about third-party org?
[17:58:23] <mrose> my sense is that it is for defensive purposes... of course, they may find it more trouble than it's worth... who can say?
[17:58:30] <psa> HK: not sure if considered
[17:58:43] <psa> Nathaniel Borenstein: relax :-)
[17:58:50] <gconnor> (side note, I wonder if there has ever been a case where someone sued over an idea? or an rfc?)
[17:58:58] <psa> NB: important to IBM that this be available to everyone for free
[17:59:53] <psa> NB (implicitly): and I think this will happen (it will be available for free)
[17:59:55] <yakovsh> gconnor: look at http://www.eff.org/patent/
[18:00:05] <gconnor> (also side note, they may not even get the patent they want. I wonder if we can contact USPTO directly and contest their application)
[18:00:16] <marcos.sanz> Can somebody tell me why does PHB have a rat in his left hand?
[18:00:22] <psa> PHB: we are trying to ensure that open-source software can propagate
[18:00:23] <yakovsh> gconnor: look http://www.pubpat.org/
[18:00:27] --- Corby has left
[18:00:49] <yakovsh> gconnor: the w3c has challenge a browser patent recently with the uspto, it is possible
[18:01:01] <yakovsh> gconnor: challenged
[18:01:07] <psa> NB: at IBM we have some experience with defensive patents and have found with hack that software can be released open-source as long as they are in separate "packs"
[18:01:57] <psa> NB: there is some packaging hack but I think the lawyers need to provide further information
[18:02:24] <psa> DC: we are a roomful of non-lawyers, not sure this is productive
[18:02:32] <gconnor> (the first note was intended more along the lines of, if there is no "defensive" patent and license, who would actually sue MS over their contribution or WG participation?)
[18:02:41] <psa> DC: we really need to do engineering and project management
[18:02:47] <gconnor> (ie. who are they defending against?)
[18:02:51] <yakovsh> gconnor: (from the audio it seems yes)
[18:03:07] <resnick> gconner: No, you missed it:
[18:03:40] <resnick> gconner: They want to prevent anyone who might use Sender-ID from suing them over *anything* else.
[18:03:53] <psa> DC: IPR issues drag on, so inappropriate to beat up MS -- we need to get this resolved or move on
[18:03:55] <yakovsh> resnick: for example?
[18:04:14] <gconnor> resnick: I get it, like "reactive" armor
[18:04:27] * resnick nods
[18:04:29] <gconnor> my stick is bigger than your stick
[18:04:38] <yakovsh> (chairs talking about closure)
[18:04:38] <psa> mrose: situation is: we want closure, and here is how we will pursue it
[18:04:40] <qpathname> yakovsh: well, let's say MS infringes on your patent which is related to email/auth/whatever, do you sue them and lose your Sender-ID license?
[18:04:45] <gconnor> so basically they are using the WG to add to their "defensive" portfolio
[18:04:46] <resnick> It's more like "mutually assured destruction":
[18:04:47] <psa> mrose: we will set a date for WGLC on core doc
[18:05:03] <resnick> "I've got a nuke too, so don't sue me or I'll sue you back."
[18:05:03] <psa> mrose: everyone will have opportunity to present final wording on licensing etc.
[18:05:17] <psa> mrose: during WGLC, we will come to conclusion
[18:05:28] <qpathname> resnick: there are nukes (patents) and there are NUKES (patents that are needed for RFCs)
[18:05:28] <psa> mrose: WGLC will be line in the sand
[18:05:29] <gconnor> now I feel dirty. I participated in MARID and I have to go take a shower.
[18:05:41] <yakovsh> lol
[18:05:42] <psa> mrose: acceptable to ADs?
[18:05:43] <resnick> heh
[18:05:52] <psa> TH: this seems fair
[18:06:13] <gconnor> HA
[18:06:46] --- mitsubachi has joined
[18:06:51] <psa> mrose: need to have the technical discussion so that we can determine a date for the WGLC by 5:15 local time
[18:07:06] <yakovsh> what's the local time in san diego?
[18:07:06] <psa> mrose: time to move on to discussion of core document
[18:07:11] <gconnor> setting a deadline is fair. MS dragging it out to this far has NOT been fair.
[18:07:13] <psa> oops, sorry
[18:07:13] <qpathname> 4:18pm
[18:07:18] <mrose> 16:18 us/pacific
[18:07:20] <psa> 16:19 local
[18:07:37] <psa> s/5:15/17:15/
[18:07:46] <psa> Jim Lyons, MS on Sender-ID
[18:08:09] <psa> who claims to have most proximately introduced into the email system?
[18:08:13] <psa> does that person's domain accept responsibility?
[18:08:37] <hadmut> Will there be some minutes or a summery of today's sessions (except for the jabber log) ?
[18:08:38] --- Harry has joined
[18:08:47] <psa> who claims: find message header, first of resent-sender, resent-from, sender, from
[18:08:56] <psa> this is "PRA"
[18:08:58] <yakovsh> is there a copy of slide online?
[18:09:02] <psa> purported responsible address
[18:09:10] <psa> yakovsh: probably
[18:09:14] <mrose> yakovsh - regrettably no
[18:09:19] <psa> ah
[18:09:28] <mrose> i'll see if i can email to the mailing list
[18:09:28] <psa> does domain accept responsibility?
[18:09:35] <psa> from PRA, extract domain name
[18:09:44] <psa> find that domain's TXT record in DNS
[18:10:00] <psa> record descibes which MTAs are authorized to speak for that domain
[18:10:03] <psa> 3 drafts
[18:10:15] <psa> core-02, protocol-00, submitter-02
[18:10:23] <psa> core: PRA, overview
[18:10:30] <psa> protocol: format and meaning of DNS record
[18:10:34] <qpathname> splitting PRA out is a horrible idea
[18:10:54] <psa> submitter: optional SMTP extension for performance optimization
[18:11:21] <psa> changes ..... xml record removed
[18:11:22] <gconnor> q: I disagree, given that we may need to ditch PRA. I would love to have three RFC's and be able to proceed with 2 of them if MS will not give fairly
[18:11:38] <psa> record format moved to protocol-00
[18:11:45] <psa> removed nonstandard headers
[18:11:54] <psa> defined behavior for malformed headers in PRA
[18:12:01] <psa> set of results now matches SPF
[18:12:05] <rand@sendmail.com> Umm, there are three RFCs
[18:12:15] <mrose> s/RFCs/I-Ds/
[18:12:19] --- paf has left: Disconnected
[18:12:20] <rand@sendmail.com> yes
[18:12:23] <rand@sendmail.com> thanks
[18:12:34] <psa> rand: core, protocol, submitter
[18:12:44] <rand@sendmail.com> yes, I count three
[18:13:30] --- Harry has left
[18:14:31] --- paf has joined
[18:15:08] <psa> PR: Doug is suggesting that PRA algorithm is not enough to validate domain
[18:15:28] --- Harry has joined
[18:15:43] <psa> suggesting different algorithm, or changes to this algorithm?
[18:15:56] <rand@sendmail.com> validate a domain for the purposes of an accreditation check
[18:16:06] <Harry> I've emailed my slides and Jim's to the list.
[18:16:13] <gconnor> That would be Doug's opinion
[18:16:18] <psa> DO: first auth EHLO domain
[18:16:19] <gconnor> I disagree
[18:16:19] <rand@sendmail.com> yes, doug's opinion
[18:16:50] <gconnor> It's really up to the accrediting agent.
[18:17:10] <mitsubachi> harry, thanks
[18:17:30] <psa> DO: would be happy to write a draft that explains my preferred approach
[18:17:49] <yakovsh> harry: pra is section 4 of the rfc?
[18:17:57] --- Corby has joined
[18:18:01] <psa> DC: this is out of order, but...
[18:18:11] --- ocin has joined
[18:18:52] <psa> DC: my reading of the WG list does not have consensus
[18:19:19] <psa> DC: simply not clear to me based on WG meeting and list discussion to date
[18:19:21] <Harry> Yakov: yes, section 4 of the marid-core I-D.
[18:19:32] --- admcd has left
[18:19:36] <psa> Chairs note the concern
[18:19:51] --- admcd has joined
[18:19:52] <psa> Jim Fenton: dependencies on the order of headers are a bad thing, no?
[18:20:09] <psa> JF: has this been vetted with the SMTP wizards?
[18:21:06] <psa> Mark L.: resent blocks and order are defined in 2822
[18:21:23] <psa> ML: not really a strange order of the headers
[18:21:42] <psa> ML: looking at Sender and From after resent-block is defined
[18:22:27] <psa> Jim Fenton: concern about security considerations
[18:22:31] <psa> JF: plans to complete it?
[18:22:45] <psa> JF: I can think of attacks that are not described there
[18:23:17] <wrs1864> that should be protocol discussion
[18:23:59] <psa> DC: need to get operations review as well
[18:24:20] <psa> DC: email geek review would be very helpful as well
[18:24:52] <psa> Andy: we are looking into the reviews and will make announcement about them soon
[18:25:14] --- Corby has left: Disconnected
[18:25:25] <psa> JL: this is new territory for standards, but not for existing practice by large ISPs etc.
[18:25:35] --- Corby has joined
[18:26:06] <psa> DC: I could not disagree with you more -- existing practice does not speak to major changes to global service
[18:26:12] <psa> (at a standards level)
[18:26:27] --- jakob has left: Disconnected
[18:26:43] <gconnor> Major changes like, restricting our mailservers so they are not open relays/
[18:26:45] <gconnor> ?
[18:26:45] <psa> Andy: any other questions for Jim?
[18:26:59] <psa> mrose: sense of the room...
[18:27:27] <psa> mrose: does anyone think that if we spend 6 months to six years on the docs as they stand, will they be substantially better?
[18:27:45] <psa> s/substantially/demonstrably/
[18:27:58] <resnick> Andrew Donoho
[18:28:04] <psa> Andrew Donahue: we are asking MTA vendors to add new steps to they way they use the protocol
[18:28:12] <psa> misspell, sorry
[18:28:18] <rand@sendmail.com> these mics are poor
[18:28:23] <gconnor> PHB pointed out in another session: we are better and faster at producing standards and revising them later than producing perfect standards out of the gate
[18:28:33] <psa> AD: since SMTP has weaknesses, are we addressing all the weaknesses?
[18:28:34] <qpathname> out of scope
[18:28:51] <psa> mrose: w.r.t. charter, that question will not be addressed
[18:28:53] --- JohnThielens has left: Replaced by new connection
[18:29:15] --- JohnThielens has joined
[18:29:20] <psa> mrose: yes, this is a serious issue, but it is out of scope for this WG as chartered
[18:29:37] <psa> mrose: you should talk with the AppsArea ADs
[18:29:43] <psa> John Wesley...
[18:29:44] <mengwong> John Leslie.
[18:29:53] <psa> sorry
[18:30:44] <psa> JL: we are short-circuiting the IETF process here -- following the full process would result in better documents
[18:31:51] <qpathname> is Nathaniel Borenstein here?
[18:31:54] <mengwong> y
[18:31:54] --- robertml has joined
[18:32:01] <psa> John Levine: yes, we could make it demonstrably better in 6 months -- depending on what we do during those six months
[18:32:03] <psa> qp: yes
[18:32:07] <mtnviewmark> Nathaniel Borenstein is in the room
[18:32:17] <psa> JL: concerned that we have no operational experience with Sender-ID
[18:32:21] <qpathname> (on jabber)
[18:33:03] <psa> JL: e.g., concerns about large TCP packets not being processed correctly
[18:33:12] <gconnor> RTS: More important question, would waiting 6 months improve it enough so that people suffering spam overload now will later agree, "I'm glad you guys waited 6 more months"
[18:33:27] <hardie> Is Rodney in the room?
[18:33:31] <psa> gconnor: +1
[18:34:00] <rand@sendmail.com> gconnor: +2
[18:34:06] <psa> DC asks some questions....
[18:34:14] <mengwong> channelling socrates...
[18:34:18] <psa> heh
[18:34:30] <gconnor> If someone would like to repeat my question that woudl be cool
[18:34:30] <wrs1864> gconnor: rts == "please channel this question"?
[18:34:36] <gconnor> yes
[18:34:54] <psa> mrose: trying to address the 90/10 rule
[18:35:18] <gconnor> (I said "rts" because so far marshall has been channeling questions, or at least he was the one reporting back)
[18:36:06] <psa> DC: issue John Levine raised speaks to the need to address the implications
[18:36:20] <psa> DC: very worried about the implications
[18:36:45] <mengwong> Margaret Olson
[18:36:48] <mrose> and mtr is also worried about the implications
[18:36:51] <psa> Margaret: it is desirable to test before making them standards
[18:37:14] <mengwong> go geeks!
[18:37:20] <psa> M.O.: e.g., only a small percentage of people have deployed SPF
[18:37:41] <rand@sendmail.com> I wonder if someone should mention that we can't really test until the IPR issues are addressed
[18:37:58] <qpathname> One quick comment if someone could add to what M.O. is saying for me "Not just what Margaret said, but 90% of the sites implementing SPF already are using softfail or neutral - so even there we don't really know the full effects."
[18:38:02] <psa> M.O.: response I get from people is "as soon as it's a standard, we'll look at it"
[18:38:16] <yakovsh> sounds like she is saying that its a catch 22
[18:38:21] <qpathname> "not many sites are using hard fail"
[18:38:54] <mengwong> not many sites are using hard fail because everybody's waiting for the forwarders. the forwarders may be waiting for more sites to use hard fail.
[18:38:55] <psa> Doug Otis: I think there is possible improvement and that we can provide better results with simple mechanisms
[18:38:56] --- rpayne has left: Logged out
[18:39:07] <psa> Doug Otis: I will put together a draft
[18:39:08] --- nsb has joined
[18:39:23] --- peterd has left
[18:39:25] <rand@sendmail.com> I want to look at comparisons between Sender ID results compared with classical spam filter results on the same messages
[18:39:47] <qpathname> rand: we have that for the SpamAssassin corpora
[18:39:53] <rand@sendmail.com> See if there is going to be a false positive problem
[18:40:01] <psa> PHB: I think we have a pretty good draft that a competent programmer can code to
[18:40:03] <qpathname> rand: there's definitely a FP problem :-)
[18:40:24] <psa> PHB: not clear what the incompetent programmer would do
[18:40:28] <gconnor> go phb!
[18:40:28] <mtnviewmark> rand, et. al: I have a script you can run if you have a corpus of mail sorted into spam/ham
[18:40:29] <mengwong> Murray from Sendmail.
[18:40:45] <psa> Murray @ sendmail: we have no real-world data that this set of algorithms would work well
[18:40:57] --- Kurt has joined
[18:40:59] --- robertml has left
[18:41:10] <yakovsh> isn't this what "proposed standard" status in the ietf is meant for?
[18:41:52] <psa> Jim Fenton: suggest that we separate submitter draft from other 2 drafts
[18:42:02] --- malamud has left: Disconnected
[18:42:28] <psa> JF: submitter seems more controversial and an extension/optimization
[18:42:48] --- RandyG has left: Disconnected
[18:43:26] <psa> Pete Resnick: I think submitter could stand an edit or two, but I don't think it's 6 months
[18:43:54] <psa> Michael Connor: I think submitter is an optimization that could be easily split off
[18:43:55] --- ocin has left: Logged out
[18:44:09] --- hkruse has left: Disconnected
[18:44:53] --- ocin has joined
[18:44:53] <psa> Martin Duerst: if you want to deploy, better to have a complete package
[18:44:59] <fenton> s/Michael Connor/Michael Thomas/
[18:45:21] <psa> Ned Freed: agree with Martin
[18:45:24] <psa> fenton: thanks
[18:45:55] --- RoyArends has joined
[18:46:04] --- hkruse has joined
[18:46:12] <qpathname> hrm... I lost my audio feed
[18:46:21] <wrs1864> ditto
[18:46:23] <gconnor> me too
[18:46:24] <galvinjamesm> lost mine too but it just came back
[18:46:32] <mrose> no, you just went deaf from listening to all this stuff for several hours
[18:46:42] <psa> PHB: my experience with SAML was that later drafts were not reviewed as closely
[18:46:48] <qpathname> got mine back now
[18:46:49] <rand@sendmail.com> qpathname: have you published those SpamAssassin corpora results?
[18:46:57] <psa> PHB: comments that matter come in the form of code
[18:47:10] <eric_allman> still no audio here, sigh.
[18:47:23] --- RoyArends has left
[18:47:27] <yakovsh> audio leaving and coming back sporadically
[18:47:29] <gconnor> it came back
[18:47:31] <gconnor> try realod
[18:47:38] <eric_allman> it's back now
[18:47:46] <yakovsh> i am using an mp3 stream
[18:48:03] <eric_allman> and gone again
[18:48:09] <eric_allman> and now back
[18:48:17] <psa> Andrew Donaho: we could force EHLO checking too, no? an example of what we could do better
[18:48:21] <mengwong> Andrew: let's deprecate HELO laxity and require that the HELO hostname resolve to the SMTP client
[18:48:56] <psa> Dave Crocker: I don't trust the "we have to hurry" line of thinking
[18:49:19] <psa> DC: pressure of fighting spam is not going away, we will have more windows
[18:49:53] <psa> sorry, missed the last comment
[18:50:16] <rand@sendmail.com> "Microsoft legal team", "golf course accident", etc
[18:50:22] <rand@sendmail.com> (by Ted Hardie)
[18:50:24] <psa> before that
[18:50:41] <psa> mrose: I think we shold call for closure and then WGLC
[18:50:46] <psa> WGLC as forcing function
[18:50:56] <psa> to make go / no-go decision
[18:51:11] <psa> mrose: floating a few dates for WGLC
[18:51:19] --- Kurt has left
[18:51:35] <psa> mrose: revise and publish revised versions by Friday, August 13
[18:51:51] <psa> mrose: WGLC start Monday, August 23
[18:52:03] <psa> mrose: two week WGLC
[18:52:07] <psa> and that's it
[18:52:19] <psa> is this really unreasonable, or merely unreasonable?
[18:52:25] <psa> hum
[18:52:46] <psa> hum for merely unreasonable
[18:52:53] <qpathname> rand@sendmail.com: um, they're on a public website, but not easily interpreted without a bit of explanation
[18:53:32] <psa> Mike Schmidt: would this include splitting the docs?
[18:53:49] <psa> MS: do we need to reach consensus on that today?
[18:54:20] <psa> Andy: (1) reach consensus on splitting out PRA?
[18:54:21] <psa> hum...
[18:54:30] <gconnor> mmmmm
[18:54:31] <psa> hum to split out PRA
[18:54:50] <qpathname> argh, now I wish I could hum along with leave it in
[18:55:00] <psa> Mike Smith again: does not seem that we have consensus
[18:55:11] <psa> hum seemingly conclusive
[18:55:30] <psa> rephrase: would anybody find it materially harming to split PRA out?
[18:55:31] <wrs1864> can someone channel a question: Will the chairs consider alternatives I-D(s) for the PRA so in case the IPR issues fail, the rest of Sender ID can progress?
[18:55:33] <qpathname> yes!
[18:56:35] <psa> wrs1864: Andy will address in a sec
[18:56:35] --- amelnikov has joined
[18:56:36] --- Kurt has joined
[18:56:38] <rand@sendmail.com> qpathname: have a URL for those results? I can try to confound myself for a while. ;)
[18:56:51] <qpathname> Can someone phrase this out for me: "Leaving PRA in the document seems to be the best way to encourage Microsoft to free up the license. Are we sure they don't have other patents???"
[18:57:08] <mrose> judgement: core document will be split into two docs, one on pra.
[18:57:09] <psa> Andy: (2) would submitter be considered in WGLC?
[18:57:17] <psa> mrose: yes, thanks
[18:57:41] <gconnor> mmmmm
[18:57:42] <eric_allman> submitter should be considered.....
[18:58:11] <resnick> I think the only question is "at the same time?"
[18:58:20] * qpathname sighs
[18:58:24] <mrose> judgement: as to whether or not submitter goes forward is dependent on the wglc.
[18:58:49] <psa> question of order: when do we expect work to start on the undefined record?
[18:59:16] <psa> Mark: only the number has not been assigned -- the format is defined
[18:59:18] --- mtnviewmark has left: Disconnected
[18:59:37] --- mtnviewmark has joined
[18:59:53] --- kjd has left: Replaced by new connection
[19:00:14] <yakovsh> which draft defines the format?
[19:00:34] <mengwong> can we have a summary of the recent hums?
[19:00:38] <yakovsh> found it
[19:00:48] --- robertml has joined
[19:00:58] <psa> Dave Crocker: does this last call include a statement of what status these docs will have?
[19:01:04] <mrose> draft-ietf-marid-protocol
[19:01:21] <psa> WGLC on each document separately, or on set of docs?>
[19:01:22] --- orange has left: Disconnected
[19:02:07] --- Kurt has left
[19:02:42] <psa> mengwong: (1) we will split PRA into another I-D; (2) submitter would be considered in WGLC
[19:02:56] <mengwong> thanx.
[19:02:59] <psa> missed PAF's comment
[19:03:11] --- Corby has left: Replaced by new connection
[19:03:16] <yakovsh> he is asking for review of our drafts by DNSEXT
[19:03:21] --- Corby has joined
[19:03:23] <resnick> PAF: Pass the new RR text to DNSEXT WG now.
[19:04:11] <mrose> can folks with questions, please restate them.
[19:04:12] <psa> mrose channels the chatroom questions
[19:04:32] <mengwong> wrs1864: can someone channel a question: Will the chairs consider alternatives I-D(s) for the PRA so in case the IPR issues fail, the rest of Sender ID can progress?
[19:04:33] <resnick> Rob Austein: Will need to send some specific queries along with the text to DNSEXT.
[19:05:22] --- mlshore has left: Disconnected
[19:05:27] <psa> andy: need to be submitted to drafts repository first
[19:05:44] <psa> andy: if we see alternative proposals now, could be confusing
[19:05:53] <psa> andy: consider only if WGLC fails to produce documents
[19:06:15] <yakovsh> rtf: what about an algorithm from older drafts such as rmx, dmp?
[19:06:17] <yakovsh> spf
[19:06:23] <yakovsh> can someone channel that?
[19:06:39] <mengwong> yakov, do you mean choice of identity, rather than algorithm?
[19:06:49] <mengwong> because the algorithm is the same for spf and sender id, but the choice of identity differs.
[19:06:55] <yakovsh> algorithm
[19:07:10] <psa> mrose to Doug Otis: would be helpful for you to complete your proposal soon
[19:07:26] <mengwong> can you explain "choice of algorithm"?
[19:07:30] <psa> Scott Hollenbeck: document set has to be complete in order to be sent up to the IESG
[19:08:04] <galvinjamesm> lost audio...
[19:08:04] <mrose> co-chairs agree
[19:08:22] <resnick> jim: nothing we can do from here. :(
[19:08:27] <mrose> the rmx/dmp question has been asked
[19:08:29] <psa> andy: helpful for people to generate their alternative proposals soon, but concerned that it would be distracting for the WG list, which is already quite high volume already
[19:08:52] <mrose> jim: wish i could selectively go deaf...
[19:08:56] <galvinjamesm> pr: I know. just looking for comisery. it just came back though.
[19:09:01] <psa> andy: get those submitted or updated and if WGLC determines that alternatives are needed, will consider at that time
[19:09:18] <psa> judgement: revised drafts submitted by Aug 13, WGLC starts Aug 23
[19:09:26] <qpathname> mengwong: I guess we're splitting out PRA, eh?
[19:09:30] <psa> any other questions from the chatroom?
[19:09:34] <psa> qpathname: yes
[19:10:03] <mrose> judgement: revised drafts due 8/13, ipr statements due 8/23, wglc start 8/23
[19:10:12] <qpathname> psa: I did have a question, above
[19:10:16] <psa> moving on to CSV now
[19:10:28] <qpathname> psa: related to PRA, so it's probably too late to ask
[19:11:03] <gconnor> mrose, psa, ggm, thanks for note-taking and relaying
[19:11:12] <psa> qp: you have time during setup here
[19:11:16] <psa> gconnor: a pleasure
[19:11:24] --- leslie has left
[19:11:31] * gconnor goes idle
[19:11:41] --- gconnor is now known as gconnor_away
[19:11:45] <qpathname> psa: I'm not there, so someone would need to ask
[19:11:49] <psa> <qpathname> Can someone phrase this out for me: "Leaving PRA in the document seems to be the best way to encourage Microsoft to free up the license. Are we sure they don't have other patents???"
[19:11:49] <qpathname> let me rephrase it
[19:12:08] <psa> on to CSV, perhaps bring it up with the Chairs?
[19:12:18] <psa> Dave Crocker: CSV
[19:12:23] <qpathname> "Leaving PRA in the document seems to be the best way to encourage Microsoft to free up the license, are we really sure we want to split out PRA -- what if MS has other patents?"
[19:12:25] <psa> Client SMTP Validation
[19:12:30] <qpathname> wait to ask until we're done with CSV
[19:12:38] <qpathname> it's not a huge deal
[19:12:43] <psa> http://brandenburg.com/CSV
[19:13:11] <psa> see URL for description
[19:13:36] <psa> CSV tries to answer two questions:
[19:13:38] <psa> (1) Does a domain's management authorize this MTA to be sending email?
[19:13:56] <psa> (2) Do independent accreditation services consider that domain's policies and practices sufficient for controlling email abuse?
[19:14:25] --- robertml has left: Logged out
[19:15:05] <psa> DC: key point is about MTA, not any particular message
[19:15:40] <psa> DC walks through process
[19:15:52] <mengwong> identification: who does this purport to be? authentication: is it really them? authorization: what are they allowed to do? accreditation: what do i think of the agency giving them that permission?
[19:15:53] <psa> identification, authn, authz, accreditation
[19:16:22] <psa> http://brandenburg.com/CSV/draft-ietf-marid-csv-intro-01.html#rfc.section.2
[19:17:26] <psa> identification: CSV uses the domain name supplied by a client in the SMTP HELO/EHLO.
[19:17:28] --- pigdog has joined
[19:18:00] <psa> authentication: forward A-record lookup (By finding the sending SMTP client's actual IP address, in the list of IP addresses returned by a DNS Address query on the EHLO domain-name, CSV satisfies the minimal authentication needs of this task.)
[19:18:19] <psa> authorization: CSV specifies a DNS-based record that states whether an associated host has permission to operate as a client MTA
[19:18:42] <psa> accreditation: CSV defines a DNS record that permits domains to announce the accreditation services in which they are listed. It also defines a separate record by which accreditation services publish their assessments of sending domains.
[19:18:54] --- hkruse has left: Disconnected
[19:19:07] --- aen has left
[19:19:11] --- dblacka has left
[19:19:16] --- SAH has left
[19:19:54] --- orange has joined
[19:19:57] --- ogud has left
[19:19:59] --- sakai has left
[19:20:34] --- robertml has joined
[19:21:05] <psa> Rand @ sendmail: is there a way to indicate that if you receive mail from a non-listed MTA, don't take that as failure?
[19:21:17] <psa> DC: this is a concern
[19:21:50] <psa> DC:, no failure does not really tell you anything
[19:22:13] <mtnviewmark> are we discussing CSV technically? or only discussing time-lines and milestones?
[19:22:20] <psa> technically
[19:22:26] <psa> or so it seems
[19:22:43] <mtnviewmark> that was sort of a question for the chairs....
[19:22:44] <mrose> a little of both.
[19:22:50] <psa> question about chaining
[19:22:55] --- leg has left: Lost connection
[19:22:58] <psa> mtn: understood
[19:22:59] <resnick> (kent crispin)
[19:23:09] <mengwong> as a channel mechanism, CSV is a pairwise thing.
[19:23:12] <psa> DC: pairwise
[19:23:33] --- jakob has joined
[19:24:14] <psa> DC: all of these mechanisms must be seen as providing incremental information
[19:24:47] <psa> I missed John Leslie's comment
[19:24:58] <psa> scribe fatigue has set in
[19:25:28] <psa> PHB: whichever authentication mechanism you use any accreditation method
[19:25:34] <psa> oops
[19:25:37] <psa> that doesn't parse
[19:25:50] --- Corby has left
[19:26:11] <psa> PHB: whichever authentication mechanism you use, you should be able to use any accreditation method
[19:26:22] --- ocin has left: Logged out
[19:26:32] <psa> PHB: going to need more than one protocol on the back end for accreditation
[19:26:38] <rand@sendmail.com> what worries me about that is that the different authentication schemes are authenticating different things
[19:27:30] <psa> chairs: timeline and milestones for CSV?
[19:27:30] <rand@sendmail.com> so you can't have accreditation of the channel (CSV) map directly to accreditation of the original sender (DomainKeys)
[19:27:38] --- jakob has left: Disconnected
[19:27:49] --- hp has left
[19:28:27] --- leg has joined
[19:28:43] --- admcd has left: Disconnected
[19:28:57] --- jis has left: Disconnected
[19:30:19] <psa> Andy: it would not please the chairs to receive new work items regarding accreditation
[19:30:58] <psa> Andy: we will point to those, but defining them is out of scope
[19:31:32] <psa> PHB: are we back-dooring accreditation?
[19:31:47] --- paf has left: Disconnected
[19:31:56] <resnick> (i.e., could we throw something into Sender-ID too?)
[19:31:58] --- warlord has left
[19:32:49] <mengwong> i would point out that the spf protocol reserves an accredit modifier.
[19:33:02] <psa> PHB: perhaps address accreditation in a separate WG?
[19:33:13] --- jis has joined
[19:33:29] <resnick> DNA hasn't been accepted as a WG I-D yet, has it?
[19:33:37] --- pigdog has left: Disconnected
[19:33:37] <rand@sendmail.com> I believe it has
[19:33:44] <rand@sendmail.com> linked from the MARID charter page
[19:33:47] <resnick> Ah....hmmmmm
[19:33:56] --- jis has left: Disconnected
[19:33:59] <psa> http://www.ietf.org/html.charters/marid-charter.html
[19:34:00] <yakovsh> http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt
[19:34:20] <psa> Andy: timeline and milestones
[19:34:21] --- orange has left: Disconnected
[19:34:38] --- amelnikov has left
[19:34:46] <resnick> OK, that changes my thoughts about this discussion a bit. (Not that I think it's a wildly problematic issue anyway.)
[19:35:37] <psa> DC: I think we can do quicker than IETF 61
[19:36:04] --- Harry has left
[19:36:24] <psa> DC: we think CSV is really simple stuff and hopefully we can get agreement on it quickly -- not sure what feedback people will really have on this
[19:36:31] --- resnick has left: Disconnected
[19:36:39] --- AndrewD has left
[19:36:41] <psa> DC: target last call for second week of October?
[19:37:20] --- leg has left: Lost connection
[19:37:28] --- yakovsh has left
[19:37:57] <wrs1864> I wonder if the DNS folks will object as strongly to the abuse of the SRV RR type as they did about the use of the TXT RR type....
[19:38:06] <psa> any objections to WGLC regarding CSV on October 12?
[19:38:11] <psa> no objections
[19:38:19] --- yone has left
[19:38:21] <psa> Andy: call for feedback
[19:38:22] <mrose> october 11th, not 12th
[19:38:25] <psa> sorry
[19:38:25] --- mtnviewmark has left: Disconnected
[19:38:27] <psa> </end>
[19:38:30] --- fenton has left
[19:38:30] --- hardie has left
[19:38:33] <marcos.sanz> Thanks to psa for the logs
[19:38:33] --- rand@sendmail.com has left: Disconnected.
[19:38:35] --- pawal has left: Disconnected
[19:38:36] <psa> session over
[19:38:37] --- DouglasOtis has left
[19:38:38] <marcos.sanz> Great job
[19:38:42] --- andreas-b has left
[19:38:42] --- marka-isc has left
[19:38:43] --- robertml has left
[19:38:45] <qpathname> thanks scribes and thanks for the audio feed
[19:38:49] --- JohnThielens has left
[19:38:53] --- hadmut has left
[19:38:54] --- yone has joined
[19:38:56] <galvinjamesm> thanks scribes and thanks for the audio!
[19:39:01] <psa> log: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html
[19:39:07] --- yone has left
[19:39:07] <wrs1864> thanks for the scribes!
[19:39:14] * psa goes for beer
[19:39:22] --- marcos.sanz has left
[19:39:28] <galvinjamesm> (B)
[19:39:37] --- galvinjamesm has left
[19:39:49] --- stpeter has left
[19:40:07] --- eric_allman has left
[19:40:13] --- psa has left
[19:41:11] --- NFreed has left: Disconnected
[19:44:03] --- tonyhansen has left
[19:45:11] --- nsb has left: Disconnected.
[19:48:12] --- wrs1864 has left
[19:50:23] --- andy has left
[19:50:30] --- vlevigneron has left: Disconnected
[19:51:52] --- mrose has left
[19:52:07] --- qpathname has left
[19:53:59] --- danwing has left: Disconnected
[19:56:40] --- edmundo.cazarez has left: Disconnected
[19:59:33] --- robertml has joined
[20:01:36] --- mengwong has left: Disconnected
[20:06:33] --- SamSilberman has left: Disconnected
[20:08:48] --- robertml has left: Disconnected
[20:09:43] --- yakovsh has joined
[20:09:56] --- yakovsh has left
[20:24:13] --- leifj has left: Disconnected
[20:30:30] --- orange has joined
[20:31:09] --- orange has left
[20:38:18] --- malamud has joined
[20:40:14] --- leifj has joined
[20:40:28] --- malamud has left: Disconnected
[20:44:17] --- leifj has left
[20:49:10] --- hadmut has joined
[21:14:12] --- vlevigneron has joined
[21:17:40] --- leg has joined
[21:18:44] --- hadmut has left
[21:24:24] --- resnick has joined
[21:25:14] --- malamud has joined
[21:28:56] --- leg has left
[21:29:05] --- paf has joined
[21:32:11] --- paf has left
[21:33:20] --- RandyG has joined
[21:47:29] --- malamud has left
[22:08:48] --- vlevigneron has left: Disconnected
[22:09:36] --- vlevigneron has joined
[22:14:00] --- ogud has joined
[22:14:28] --- ogud has left
[22:21:13] --- mitsubachi has left
[22:25:25] --- resnick has left: Lost connection
[22:31:40] --- mengwong has joined
[22:32:34] --- mengwong has left
[22:35:51] --- SamSilberman has joined
[22:59:47] --- raj has joined
[22:59:58] --- raj has left: Disconnected
[23:00:51] --- raj has joined
[23:00:56] --- raj has left: Disconnected
[23:03:36] --- SamSilberman has left: Replaced by new connection
[23:03:38] --- SamSilberman has joined
[23:07:07] --- jakob has joined
[23:14:44] --- jakob has left
[23:17:31] --- SamSilberman has left
[23:28:22] --- vlevigneron has left: Disconnected
[23:41:23] --- RandyG has left: Disconnected