[09:14:39] --- dcrocker has left: Replaced by new connection
[09:14:40] --- dcrocker has joined
[09:47:36] --- eric has joined
[10:17:48] --- sm-msk has joined
[10:27:06] --- sftcd has joined
[10:27:17] --- dcrocker has left
[10:27:25] * sftcd has set the topic to: DKIM meeting in about 30 mins...
[10:27:52] <sm-msk> hey stephen
[10:28:16] <sftcd> hi sm-msk (?)
[10:28:16] --- Barry Leiba has left: Lost connection
[10:28:22] <sm-msk> murray from sendmail
[10:28:30] <sftcd> but of course!
[10:28:34] <sm-msk> heh
[10:28:39] <sftcd> is that a real Eric there too?
[10:28:50] --- Barry Leiba has joined
[10:28:59] <sftcd> Hi barry
[10:29:02] <Barry Leiba> 'lo
[10:29:07] <eric> yep, i'm here.
[10:31:03] <Barry Leiba> Just back from my blood donation.
[10:31:28] <Barry Leiba> So if I disappear, call the paramedics and have them put my head between my legs.
[10:31:44] <sftcd> weather here is nice (aka unusual) so keeping it short today would be good for me
[10:32:08] <Barry Leiba> Nice weather is unusual for the Emerald Isle? I thought you lived in paradise.
[10:36:36] <sm-msk> nice here for the next week or so too
[10:37:05] <eric> do we have an agenda?
[10:37:57] <eric> ah, i see stephen says he's coming up with an agenda now.
[10:38:24] <eric> i would like to include Jim's question of whether listing the DKIM_STAT_ codes is a good idea or not.
[10:38:39] <sm-msk> he said that?
[10:38:46] <eric> email yesterday.
[10:38:55] <sm-msk> oh
[10:39:07] <sm-msk> is there a list i'm not on?
[10:39:13] <sm-msk> there seems to be a lot of DKIM chatter i'm not seeing
[10:39:20] <eric> From: Jim Fenton <fenton@cisco.com> To: IETF-DKIM <ietf-dkim@mipassoc.org> Subject: [ietf-dkim] base-02: Verifier result codes Date-Sent: May 31, 2006 1:19:33 PM -0700 A new "feature" in base-02 is the introduction, in section 6, of DKIM_STAT_* result codes. One of the important aspects of DKIM, in my opinion, is the clarity of the result: Either a signature is valid, or it's not. While not the intent of the result codes, I think they will cause some readers to conclude that (for example) a DKIM_STAT_SYNTAX should be handled differently from a DKIM_STAT_NOKEY. I think the current discussion delves too far into the implementation of the verifier in its description, and would prefer to return to the earlier description in this respect. -Jim
[10:39:46] <eric> i assume you're on that list.
[10:39:51] <sm-msk> hm, must've just missed the digest
[10:39:52] <sm-msk> yep i am
[10:42:42] <eric> i'm getting the direct messages rather than the digest, although that shouldn't make a difference.
[10:43:42] * sftcd has set the topic to: DKIM meeting in about 15 mins...
[10:44:03] <sftcd> just posted agenda to dkim list, will send archive URL here when it hits...
[10:44:38] <sftcd> Agenda is at: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003774.html
[10:45:31] <sm-msk> well i'm here this time, huzzah
[10:45:45] <sm-msk> which way to the breakfast buffet
[10:45:57] <eric> a bit premature perhaps, but FAOYI, next week I'll be on an airplane somewhere in Europe about this time, so I won't be able to participate.
[10:46:23] <sm-msk> is this a weekly deal?
[10:46:28] <sftcd> I'll be awol (most likely) the following week fwiw
[10:46:39] <sftcd> murray: yes for now until montreal maybe
[10:46:55] <Barry Leiba> I'll be away the following week too (two weeks from today).
[10:47:02] <Barry Leiba> So I guess we won't do it in two weeks.
[10:47:15] <Barry Leiba> 'less'n someone else wants to moderate and report.
[10:47:35] <eric> damn, and that's running right into Montreal. We may have to finish it off today if we are going to have a -03 draft out by then.
[10:48:08] <sftcd> think about sending out -03 before/about then and using the hiatus to collect last call issues? that too early?
[10:48:26] <eric> define "then"
[10:48:36] <sftcd> week of june 12
[10:49:07] --- Dennis Dayman has joined
[10:49:11] <Dennis Dayman> morning all
[10:49:19] <sftcd> hiya
[10:49:21] <Dennis Dayman> Barry: loved that video
[10:49:42] <Dennis Dayman> bbiaf going to get some coffee before this
[10:49:43] <Barry Leiba> :-)
[10:49:50] <eric> yeah, that should work. the cutoff for new drafts is june 19
[10:50:12] <eric> that will give me a few days after i get back from europe to incorporate anything that has come in.
[10:50:35] <sftcd> eric: let's keep that in mind for now and see where we're at next week when more folks have read -02
[10:51:15] * sftcd has set the topic to: DKIM meeting in about 10 mins...
[10:53:02] --- doug_trendmicro@jabber.org has joined
[10:53:30] <sm-msk> did -02 get sent?
[10:53:45] --- fenton has joined
[10:54:10] <Barry Leiba> Welcome, Jim & Doug.
[10:54:16] <fenton> 'morning all
[10:54:32] <sftcd> afternoon
[10:54:33] <eric> msk: sent, as in submitted? yes, several weeks ago.
[10:54:51] <eric> may 22
[10:55:03] <sm-msk> wow, i'm behind!
[10:55:13] <sm-msk> g'day jim
[10:55:20] * sftcd has set the topic to: DKIM meeting in about 5 mins...
[10:55:24] <eric> i sent out a pointer to ietf-dkim the same day.
[10:55:26] <fenton> Hi Murray
[10:55:35] <eric> hi jim.
[10:55:46] <fenton> morning, Eric
[10:55:54] --- boxley has joined
[10:55:56] <sm-msk> i'm still not used to my new e-mail client, i wouldn't be surprised if i'm missing stuff
[10:56:14] <fenton> What's the new client?
[10:56:25] <sm-msk> mozilla with threading
[10:56:28] <sm-msk> was using pine without threading
[10:56:48] <Barry Leiba> Just got an interesting phishing message, just arrived:
[10:57:13] --- thomasm has joined
[10:57:19] <eric> i'm still on mulberry, which i completely love. pity they have gone belly up. bit rot will set in in a few years, but until then i'm holding on hard. perhaps by the time that happens other clients like thunderbird will have caught up.
[10:57:22] <Barry Leiba> It's phishing for paypal, and the "from" is spoofed as "support@paypal.com". But the "friendly" name in the from is "Chase Bank".
[10:57:40] <Barry Leiba> Mulberry here too, and I also love it.
[10:57:42] <sm-msk> Barry: it's that land shark.
[10:57:58] <eric> maybe the phisher doesn't know that paypal isn't part of Chase. or vice versa.
[10:58:18] <sftcd> or maybe they're one deal ahead of us...
[10:58:24] <Barry Leiba> He-he-he
[10:58:27] <sm-msk> hah
[10:58:36] <eric> i think i'm goin to short some stock....
[10:59:09] <fenton> is it insider trading if the tip comes from a phishing message?
[10:59:14] <Barry Leiba> On the email clients... I wish I could get the Mulberry source code, make a few changes. But mostly it's fine. And I've had serious problems with Thunderbird in offline mode.
[10:59:23] <eric> depends on whether the phisher is inside, i guess....
[10:59:31] <Barry Leiba> Anyway, looks like it's time to start. I have 30 seconds.
[10:59:35] * sftcd has set the topic to: DKIM meeting starting now...
[10:59:43] <sftcd> Suggested agenda is http://mipassoc.org/pipermail/ietf-dkim/2006q2/003774.html
[10:59:56] <sftcd> any agenda bashing items?
[11:00:17] <eric> i think we should at the end talk about procedurs from here
[11:00:33] <eric> i won't be around next week, and apparently neither barry nor stephen will be the week after.
[11:00:34] <sftcd> you mean the timeline to montreal?
[11:00:37] <eric> yes
[11:00:45] <sftcd> ok noted
[11:00:57] <sftcd> we're on for 90 minutes as agreed a while back - that ok?
[11:01:03] <eric> cool here
[11:01:10] <doug_trendmicro@jabber.org> kay
[11:01:11] <sftcd> so we'll cut issues list at 80 minutes
[11:01:16] <boxley> kay
[11:01:18] --- dcrocker has joined
[11:01:35] <sm-msk> works for me
[11:01:40] <sftcd> meanhwile onto issue 1264
[11:01:50] <sftcd> Issue 1264: "(proposed fingerprint tag description)." This was proposed by Murray, who wasn't on the jabber chat, and the participants didn't know enough about it to discuss it in Murray's absence. Issue remains open; push it back to the mailing list.
[11:02:02] <sftcd> (that's from Barry's notes from last week)
[11:02:09] <sm-msk> i need to re-post that to the list to bring it back to life
[11:02:28] <sm-msk> basically i'd planned to change the name to "si"
[11:02:31] <eric> can we get a very brief summary now?
[11:02:43] --- tonyhansen has joined
[11:02:48] <sftcd> https://rt.psg.com/Ticket/Display.html?id=1264
[11:03:10] <sm-msk> and specify that the ID can be anything you want, but stipulate that the value of "si" plus "i" together has to be unique within the message
[11:03:18] <sm-msk> the purpose is the same
[11:03:36] <sm-msk> to make sure that a signature can be identified uniquely in later result-relaying mechanisms
[11:03:55] <thomasm> what was the use case here Murray, I can't remember
[11:04:18] <sm-msk> one signing agent can add several signatures, so Auth-Results (for example) needs to be able to say result X applies to signature Y for each Y
[11:04:34] <sm-msk> that's basically the problem i need to solve
[11:04:36] <sftcd> why not just use (some/enough) signature bits?
[11:05:02] <doug_trendmicro@jabber.org> Some use a type of checksum of the key or certificate.
[11:05:05] <sm-msk> could use anything really. signature bits is one option.
[11:05:16] <sm-msk> sure, you could hash the signature and use eight bytes of the hash
[11:05:18] <eric> there's some text I don't understand: since the base64-decoded version of the "bh" tag is not easily visible upon simple header inspection, signers SHOULD add this tag for clarity.
[11:05:23] <thomasm> signature bits are pretty good though not perfect
[11:05:25] <fenton> Why do you need to associate with a specific signature, rather than just say that there's a valid signature from [i=]?
[11:05:36] <eric> what do you mean that the bh tag is not easily visible? it's as visible as si would be.
[11:05:59] <sm-msk> eric: hm, i forget why i said that at the moment...
[11:06:11] <doug_trendmicro@jabber.org> If several signatures are added to the same body, the bh would be the same.
[11:06:11] <thomasm> it's early
[11:06:16] <sm-msk> jim: suppose a sha1 signature passed but a sha256 signature failed
[11:06:28] <dcrocker> Assuming that the proposal is both useful and sufficiently specified, I would like to nonetheless suggest not including it in the first version of -base. First, it is not essential. Second, it pertains to multiple signatures, and
[11:07:02] <thomasm> that's my inclination -- I think we have some things to sort out with auth res, so it's not clear who/what is the consumer anyway
[11:07:04] <fenton> Are you saying that we want the recipient and the verifier to be able to have different rules about accepting sha1? That seems like a stretch.
[11:07:07] <dcrocker> mu.ltiple signatures are proving a tad challenging. My guess is that we do not understand their dynamics or use well enough and that we do not need to fix that, for the initial work./
[11:07:24] <sftcd> if Murray uses signature bits then we don't need to add anything to base and they ARE unique (or something else is very wrong)
[11:07:29] <thomasm> was there a non auth-res use case as well, Murray?
[11:07:36] <sm-msk> jim: it's just an example of a distinction that might be of interest to a verifier or receiver.
[11:07:58] <fenton> The verifier is the one applying auth-res, so it doesn't help there.
[11:08:12] <Barry Leiba> I don't like the idea that one might care which crypto verified.
[11:08:20] <sm-msk> right but the verifier isn't necessarily deciding on final disposition
[11:08:24] <dcrocker> Philsophy: What is driving my opinion is the belief that we are in the stage of work that should impose two requirements: 1) what is broken and needs fixing, and 2) what can we *remove* from the spec.
[11:08:25] <Barry Leiba> Either you accept a crypto algorithm, or you don't.
[11:08:56] <sftcd> folks isn't the crypto stuff moot here?
[11:08:58] <fenton> Barry: +1, and if you do it with this hash you need to go back to the signature and see what hash it used. Painful.
[11:09:29] <sftcd> so murray if we close this for base is that ok?
[11:09:39] <Barry Leiba> So I kind of think that knowing which i= verified is enough. In any case, I agree with Dave. This can be done in an extension.
[11:10:02] <sm-msk> sftcd: one sec, thinking
[11:10:03] <eric> i think it's going to prove important (gut reaction perhaps), but it can be an extension.
[11:10:13] <boxley> I think the verification vendors will happily add useful extensions
[11:10:25] <boxley> for base keep it simple as possible
[11:10:35] <eric> proprietary extensions aren't going to be very useful.
[11:10:39] <sm-msk> i'm not sure i agree that "something from i= verified" is sufficient for me to accept a message
[11:11:13] <sftcd> you may be right, but you can still reference via signature bits without changes to base
[11:11:17] <fenton> Murray: It should be if your verifier only applies auth-res to sigs that you should consider acceptable.
[11:11:31] <doug_trendmicro@jabber.org> provided the d= is included, that is all the information that is available.
[11:11:41] <sm-msk> ok but setting aside the crypto for a moment
[11:11:47] <fenton> If you don't like your verifier's policies, then ignore auth-res and verify for yourself
[11:11:54] --- tonyhansen has left
[11:11:58] <sm-msk> suppose a message is signed simple/simple and passes, but relaxed/relaxed fails (for example) using the same signature algorithm
[11:12:13] <sm-msk> result's ambiguous again
[11:12:24] <eric> sig bits will be different
[11:13:10] --- dcrocker has left
[11:13:11] <sm-msk> is that always true? i thought signatures had a few bytes at the beginning always the same for wrapper data and such
[11:13:26] <sm-msk> if not then signature bits work fine and in fact dkim-base doesn't have to change at all
[11:13:36] <thomasm> no, they're really different
[11:13:39] <eric> maybe true, but the signature will sure be different.
[11:13:40] <sm-msk> i can just say in auth-res that that's how you disambiguate
[11:13:45] <sftcd> yep
[11:13:53] <eric> you could take the first few bits of a sha of the signature, for example.
[11:14:00] <sm-msk> oh, true
[11:14:07] <sm-msk> ok, yeah, we can remove it for base
[11:14:11] <sftcd> good.
[11:14:16] <Dennis Dayman> yea
[11:14:20] <sftcd> eliot asked that we do this:
[11:14:22] <sm-msk> hey dennis
[11:14:30] <sftcd> CLOSE 1264; no need to change base
[11:14:45] <sftcd> next issue is 1265 which has been discussed a lot on the list
[11:15:00] <sftcd> so I'd be happy to say there's consensus there
[11:15:03] <sftcd> that ok?
[11:15:03] --- dcrocker has joined
[11:15:10] <fenton> works for me
[11:15:16] <eric> if you think the consensus is to leave it as is, i agree.
[11:15:16] <thomasm> me2
[11:15:18] <doug_trendmicro@jabber.org> There is the issue raised about the security considerations.
[11:15:42] <sftcd> doug - would you make that a new issue - with your suggested sec. cons. text?
[11:15:46] <fenton> doug: Parent signing *is* covered in -threats
[11:15:47] <eric> i think our conclusion is that you have to trust superdomains for reasons far more important than this.
[11:16:04] <doug_trendmicro@jabber.org> This was posted to the list already
[11:16:07] <Barry Leiba> eric: agreed, but that's a reasonable thing to put in sec considerations.
[11:16:18] <eric> oh yes, i'm not suggesting otherwise.
[11:16:24] <thomasm> could we just copy what's in -threats?
[11:16:34] <eric> does that go in threats or security considerations in -base (or both)?
[11:16:40] <sftcd> so doug, so we don't miss it can you raise a new issue just about sec. cons.?
[11:16:42] <sftcd> (just base)
[11:16:45] <fenton> do we need to copy what's in -threats?
[11:16:51] --- Eliot.Lear has joined
[11:16:57] <sftcd> no harm I guess (haven't looked)
[11:16:58] <doug_trendmicro@jabber.org> There should be a security consideration mentioning an unintended consequence when a different entity controls sub-domains of a high level domain. This could be viewed as an ICANN, ARIN, APNIC, LACNIC, and AfricNIC consideration advice. RFC1591 makes the following statement: ,--- | There are no requirements on subdomains of top-level domains | beyond the requirements on higher-level domains themselves. That | is, the requirements in this memo are applied recursively. In | particular, all subdomains shall be allowed to operate their own | domain name servers, providing in them whatever information the | subdomain manager sees fit (as long as it is true and correct). '___ There did appear to be consensus this could be viewed as requiring contractual rather than technical considerations. This requirement should be indicated within the security consideration section at least. : Security Considerations: : : Keys published by common higher-level domains : : Although TLD managers are trustees for the delegated domain, DKIM : introduces a security concern unrelated to domain delegation. : Currently there are no contractual obligations barring gTLD, ccTLD, : or SLD managers from publishing DKIM accessible keys within a :"_domainkey" sub-domain. While this sub-domain can not be : delegated as a domain due to the underscore character '_', : unqualified sub-domains in the 'i=' parameter can be constructed : to reference a key published by a higher level domain. These : higher level keys expose all sub-domains to possible harm from : a possible security breach at these higher levels. The only : protection available to owners of all sub-domains would be : established contractual obligations that currently do not exist. : The simplest remedy would be to ban inclusion of any sub-domain : beginning with the underscore '_' within these common higher-level : domains.
[11:17:13] <sftcd> doug - I meant on the list!
[11:17:22] <boxley> :-)
[11:17:27] <sftcd> ok, so....
[11:17:36] <doug_trendmicro@jabber.org> It is already posted on the list.
[11:17:41] <sftcd> CLOSE 1265; no change to base (but Doug to raise a new issue on the list)
[11:17:56] <sftcd> (doug - in a new thread so it doesn't get lost - people have to go look back for these things you know!)
[11:18:13] <doug_trendmicro@jabber.org> okay.
[11:18:30] <sftcd> ok next is...
[11:18:36] <sftcd> 1266!
[11:18:48] <sm-msk> amazing
[11:18:55] <sftcd> https://rt.psg.com/Ticket/Display.html?id=1266
[11:19:06] <Dennis Dayman> *sigh*
[11:19:07] <eric> i believe i sent out new wording last week.
[11:19:37] <sftcd> (yeah - I'm just basing on Barry's summary of last week's jabber so we can trace back)
[11:20:01] <Barry Leiba> No one commented on list to Eric's wording.
[11:20:04] <dcrocker> i like eric's new wording quite a lot.
[11:20:08] <sftcd> anyone got a URL for that new wording?
[11:20:09] --- tonyhansen has joined
[11:20:10] <Barry Leiba> I commented to Eric, basically saying that I thought it was good.
[11:20:27] <sftcd> I don't recall objecting myself (nor do I recall the words;-)
[11:20:55] <Barry Leiba> I think we've spent enough time on this one that I'm willing to say that silence is acceptance of Eric's new wording.
[11:21:00] <sftcd> me too
[11:21:01] <boxley> agreed
[11:21:08] <sm-msk> hai
[11:21:09] <Dennis Dayman> +1
[11:21:13] <Eliot.Lear> +1
[11:21:16] <fenton> check
[11:21:16] <sftcd> CLOSE 1266 - wording posted to list
[11:21:26] <sftcd> nexst 1269
[11:21:54] <sftcd> barry's note said:
[11:21:55] <sftcd> Issue 1269: "(body length mechanism rejections)." Looks like we're happy with what's in -02, but just as we start to move on there's more discussion along the "can't tell verifiers what to do" line. The original issue was an objection to advising verifiers to "reject", and the consensus on that, as advice, stays. In particular, we want to advise verifiers on determining whether a signature is *valid*, but leave the "what to do with it" part for another document (or local policy). Tony doesn't like the advice to ignore the signature. Others clarified that what we're really saying is to look at the other sigs in that case. Most accept current wording, but there's some unhappiness all 'round, so it's not optimal. Dave and Eric will collaborate on another iteration of this text, to try to resolve that and to make it clear what's normative and what's a recommendation. Issue remains open.
[11:22:41] <doug_trendmicro@jabber.org> This has already been resolved in the 02 draft has it not?
[11:22:56] <eric> dave and i went back and forth, and i think i dropped the ball.
[11:23:02] <eric> we came up with:
[11:23:10] <eric> > A body length specified in the "l=" tag of the signature > limits the number of bytes of the body passed to the > verification algorithm. All data beyond that limit cannot be > validated by DKIM. Hence, verifiers might treat a message > that contains bytes beyond the indicated body length with > suspicion, such as by truncating the message at the indicated > body length, declaring the signature invalid, or conveying > the partial verification to the policy module using > DKIM_STAT_PARTIALSIG.
[11:23:46] <sftcd> (ignoring Jim's new issue with error codes) that looks good to me
[11:23:48] <Eliot.Lear> s/cannot be verified/is not verified/
[11:23:54] <thomasm> is partialsig used elsewhere?
[11:24:19] <boxley> Eliot +1
[11:24:20] <eric> mike: i don't think so.
[11:24:24] <thomasm> that label is sort of misleading
[11:24:37] <eric> i'm not wed to it: propose something.
[11:24:55] <thomasm> maybe we should defer until Jim's item?
[11:25:04] <eric> fine with me.
[11:25:20] <sftcd> well, can we close this one though?
[11:25:28] <eric> good for me.
[11:25:36] <eric> PARTIALSIG vs something else is distinct.
[11:26:03] <sftcd> no objections to closing tihs....so....
[11:26:11] <fenton> I like the new text, with Eliot's mod.
[11:26:17] <sftcd> CLOSE 1269; wording above to be applied with Eliot's mod
[11:26:36] --- jrlevine has joined
[11:26:37] <sftcd> ok, that's all the rt.psg.com issues - or did I miss some ?
[11:26:50] <Dennis Dayman> holy cow
[11:27:02] <sftcd> if I did - chime in anytime, but meantime we have a bunch from Jim/Doug from the last few days.
[11:27:20] <sftcd> so we're on issue A - jim's nits - anything to say or just pass on?
[11:27:28] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003757.html
[11:27:33] <Eliot.Lear> i'll get those into the system sooner than later.
[11:27:46] <eric> i haven't checked them out seriously, but i suspect that they will be non-controversial.
[11:27:46] <sftcd> (thanks Eliot)
[11:28:05] <eric> i can raise something on the list if they are.
[11:28:10] <Eliot.Lear> although, jim, this one has a bunch of nits. which are not?
[11:28:11] <sftcd> Issue A: leave OPEN until -03 or stuff on list
[11:28:17] <fenton> the intent was that these are non-controversial
[11:28:39] <sftcd> Issue B - doug on threats-03
[11:28:48] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003756.html
[11:29:03] <doug_trendmicro@jabber.org> Can we adopt the base introduction?
[11:29:29] <sftcd> that was dealt with in WG LC for theats already and rejected - let's no go there
[11:30:08] <doug_trendmicro@jabber.org> The one issue related to the introduction however was a misunderstanding created at the Dallas meeting.
[11:30:26] <doug_trendmicro@jabber.org> The opportunity to comment was closed before the document was published.
[11:30:44] <doug_trendmicro@jabber.org> An interesting catch 22.
[11:31:20] <sftcd> Wrong - refer to the list - you tried to raise new things then. No catch 22 at all.
[11:31:41] <sftcd> Is there anything here that's new Doug or are they all old issues?
[11:31:47] <doug_trendmicro@jabber.org> Not the introduction however.
[11:32:27] <doug_trendmicro@jabber.org> The other issues are a rehash.
[11:32:57] <thomasm> what is the process here? this is a new draft for the AD's I thought
[11:33:09] <sftcd> yep. Jim addressed Russ' comments
[11:33:18] <sftcd> anyone else see a reason to make any of these changes?
[11:33:24] <jrlevine> I don't see anything worth reopening the threats doc. Maybe if AD's have comments later.
[11:33:28] <thomasm> no
[11:33:34] <fenton> right -- I only addressed issues raised by the AD in this revision, in order to avoid creating new issues in AD review.
[11:33:52] <sftcd> so barring more support for re-opening threats, suggest we close this?
[11:34:00] <boxley> close
[11:34:06] <thomasm> done is done
[11:34:14] <Dennis Dayman> stick a fork in it?
[11:34:33] <Eliot.Lear> is this the issue that the intros don't match and the intent was for them to do so?
[11:34:57] <doug_trendmicro@jabber.org> That was a comment also made by Jim and Eric.
[11:35:09] <fenton> Yes, the intent was that they would be the same, but if they're not, they're not.
[11:35:18] <doug_trendmicro@jabber.org> In my view, the base intro is more accurate.
[11:35:31] <eric> i haven't read the threats intro recently, but if it's acceptable i could change -base.
[11:35:52] <doug_trendmicro@jabber.org> I would not want to take that course.
[11:36:22] <sftcd> anyone else prefer one over the other?
[11:36:40] <dcrocker> uhh, are we spending group time debating the informational text known as the Introduction?
[11:36:49] <eric> yes
[11:37:00] <thomasm> I'd assume move on...
[11:37:03] <sftcd> Issue B: CLOSE; consensus not to re-open threat; eric to check out re-aligning intros
[11:37:19] <sftcd> Issue C: Jim and result codes
[11:37:28] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003758.html
[11:37:45] <sftcd> Jim doesn't like 'em
[11:38:05] <eric> i have to admit that i find them a bit too "implementation-like" for my taste.
[11:38:09] <eric> but this was by group request.
[11:38:28] <jrlevine> The only result codes that matter are YES and NO. Anything else is for debugging.
[11:38:36] <sm-msk> eric: +1
[11:38:41] <thomasm> maybe it's that they seem normative when they're more informational?
[11:38:44] <Eliot.Lear> [now issue 1283]
[11:38:50] <sftcd> [thanks]
[11:38:56] <fenton> thomasm +1
[11:39:04] <eric> this is +1 to removing them, or keeping them?
[11:39:13] <tonyhansen> I like having them there as informational
[11:39:30] <boxley> useful for debugging as long is no policy action is assumed
[11:39:39] <sftcd> hector was all for these on the list as I recall
[11:39:45] <eric> yes, he was.
[11:39:56] <sftcd> but agree they shouldn't "look" normative
[11:40:07] <eric> i can try to soften the language to make them seem less "normative-looking".
[11:40:10] <dcrocker> the distinction between a 'result' code and an 'explanation' code is well established and quite useful. DKIM has a success/fail result code. Having an explanatory code accompany this is a safe and useful and well-understood benefit.
[11:40:11] <eric> maybe not put them in all caps.
[11:40:11] <thomasm> I think there was a disconnect as Hector believed them to be normative -- at least that's what I gathered
[11:40:20] <Barry Leiba> I'll channel Paul Hoffman here: He would probably say that the verifier can do whatever the verifier wants.
[11:40:21] <fenton> No policy action is given for anything having to do with verification, so the result codes make it seem like they might affect the unstated policy
[11:40:36] <dcrocker> it's actually important to have the explanatory codes be normative, in order to press from common semantics.
[11:40:44] <eric> barry: i tried to make that explicit.
[11:40:52] <jrlevine> We do seem to be teetering on the edge of the rathole in which live vast unstated assumptions about signature semantics
[11:40:54] <dcrocker> what might be important is to make the use a MAY rather than MUST or SHOULD.
[11:41:00] <Barry Leiba> OK; I haven't read the current text there.
[11:41:06] <sftcd> so cast 'em as major/minor result codes or something? (following dave?)
[11:41:48] <sftcd> I seem to recall some GSS-API text saying not to branch on the minor result codes ('course everyone did)
[11:41:49] <dcrocker> +1
[11:41:51] <eric> let me see if I can handle it that way --- make them FAIL/foobar or something
[11:41:56] <Barry Leiba> I like Dave's distinction between "result" and "explanatory"
[11:42:08] <thomasm> I agree with John insofar as normative semantics could be a real rathole
[11:42:11] <fenton> I'm still uncomfortable with giving the impression that the result codes are to be used for anything other than debugging/
[11:42:56] <eric> i'll channel one of our engineers (claus, who only one of you knows here): what is the problem we are trying to solve?
[11:42:56] <doug_trendmicro@jabber.org> Not for filter inputs?
[11:42:57] <thomasm> why should we preclude programatic use of these different states?
[11:43:24] <boxley> If I was building a verification app I would tie result codes to my policy engine to refine results
[11:43:26] <dcrocker> i suggest viewing it as 'analysis' rather than debugging, on the theory that debugging is usually a near-term adoption requirement and analysis is periodic and ongoing.
[11:43:39] <boxley> but for a spec, informational is fine
[11:43:58] <tonyhansen> I could see some of that info being used in an auth-results
[11:44:06] <fenton> eric: the problem is we don't want to lead implementers into thinking they should do something with the result codes.
[11:44:17] <sftcd> any specific suggestions or should we just leave eric to mull over this?
[11:44:27] <boxley> mull
[11:44:28] <thomasm> the result codes, or the state Jim?
[11:44:40] <doug_trendmicro@jabber.org> And as inputs into some spam probability equation.
[11:44:57] <jrlevine> I think the problem we're trying to solve is to be sure we enumerate all the ways that a verifier can decide that it didn't verify a signature
[11:45:00] <fenton> mike - I don't understand your ?
[11:45:23] <Barry Leiba> Mulling is fine if we have an agreement here on the *concept* we want to get across.
[11:45:27] <thomasm> certainly some of the states -- like DNS unresponsive -- are useful to make different decisions
[11:45:27] <jrlevine> Re Doug, I would specifically discourage assigning semantics to different failure modes in subsequent analysis
[11:45:31] <Barry Leiba> I'm not sure we have that agreement.
[11:45:34] <eric> so it's to provide clarity about how the verifier should work?
[11:45:46] <sftcd> s/should/could/
[11:46:21] <jrlevine> yes to clarity, the verifier goes through a chain of actions, if any of them fail, the signature didn't verify
[11:46:32] <fenton> mike: yes, but I don't think we need to enumerate the way an implementation handles that in the spec.
[11:46:37] <jrlevine> but if you didn't do the whole chain, you didn't verify it right
[11:47:04] <thomasm> normatively, I agree -- informatively I think it's useful
[11:47:07] <jrlevine> (I'm not saying the steps have to be in order, just that they all have to be there)
[11:47:20] <eric> ok, how about i make it OK/FAIL with a parenthetical, informative (explanation)?
[11:47:41] <boxley> ok
[11:47:45] <fenton> I'm fine if the result codes aren't in a normative context
[11:47:47] <thomasm> that would work for me
[11:47:50] <jrlevine> ok
[11:48:01] <sftcd> trying to summarise: we dont want DKIM_STAT_* to look too normative, but aren't sure how best to do that and we don't all agree on whether or not other code should branch on these different cases
[11:48:04] <doug_trendmicro@jabber.org> ok
[11:48:12] <eric> jim, putting them all out of a normative context is going to make it really messy.
[11:48:15] <eric> lots of sub-paragraphs.
[11:48:17] <boxley> clear
[11:48:36] <thomasm> I think that your idea of parenthetical has support, Eric
[11:48:37] <fenton> eric: I think someone suggested putting this in an appendix
[11:48:45] <eric> are parentheses not good enough for you? if i make it very clear up front that they are non-normative?
[11:49:03] <sftcd> so we leave this OPEN pending a specific set of changes from Eric along the lines discussed
[11:49:04] <eric> jim: yes, that was hector. replicate them there --- he wanted a list.
[11:49:09] <sftcd> and we move on...
[11:49:18] <sftcd> Issue C: OPEN pending changes
[11:49:24] <fenton> Sure, that's fine...I definitely don't want the text too chopped up
[11:49:32] <sftcd> Issue D: Fenton, normative order of steps
[11:49:37] <eric> ok, thx
[11:49:38] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003759.html
[11:50:09] <eric> i had a response this morning about making it clear that the semantics had to be AS IF they were executed in that step, but the implementation could do what it wants
[11:50:10] <dcrocker> one again: if the codes define common semantics, they are normative. what we might need to do is to make their use optional. we might also need to make explicit that the any actions taken, based on the codes, is entirely outside the scope of the spec.
[11:50:11] <fenton> My point is I think the document is a little conflicted on how important the order is.
[11:50:24] <doug_trendmicro@jabber.org> I agree with Jim on this.
[11:50:28] <eric> there's at least one section thatalready does that
[11:50:50] <fenton> So, maybe we can just take out the sentence that says the order is important
[11:50:54] <boxley> agree with jim
[11:50:59] <tonyhansen> jim: +1
[11:51:01] <dcrocker> +1
[11:51:06] <eric> order IS important , semantically. -5
[11:51:07] <thomasm> me2
[11:51:28] <eric> i think that's a big mistake, but i'll go with the consensus.
[11:51:42] <jrlevine> order is not even AS IF, we don't care if a failure report is due to a step that wouldn't have been reached if done in official order
[11:51:47] <sftcd> can someone quote the text easily?
[11:51:56] <sm-msk> hm
[11:52:05] <fenton> "Verifiers MUST apply the following steps in the order listed."
[11:52:13] <fenton> last sentence of section 6
[11:52:29] <eric> and i'm proposing changing that to the wording used in (i think) signer actions. hold on
[11:52:31] <sftcd> (similar thing - the complicated PKI algorithm in rfc 3280 is given in exhaustive detail but with a statement that any other algorithm producing
[11:52:39] <sftcd> the same outputs s fine)
[11:52:50] <thomasm> well the MUST would be problem then
[11:53:15] <boxley> s/MUST/can/g
[11:53:36] <fenton> One question might be, whether the side effects (e.g., retrieval of public key) also need to behave in exactly the same way as what is described.
[11:53:43] <eric> i agree, the MUST is too strong in that context.
[11:53:53] <eric> side effects: no
[11:53:53] <dcrocker> What is the need for *dictating* the order, versus showing an algorithm that is known to work?
[11:54:08] <tonyhansen> Here's the list of what's included in that MUST ordering: 6.1 Extract the Signature from the Message 6.2 Get the Public Key 6.3 Compute the Verification 6.4 Communicate Verification Results 6.5 Interpret Results/Apply Local Policy 6.6 MUA Considerations
[11:54:13] <thomasm> right -- I like Stephen's example of 3280
[11:54:34] <jrlevine> order of 6.1 6.2 6.3 doesn't really matter, does it?
[11:54:45] <eric> only semantically
[11:55:03] <thomasm> eric -- really?
[11:55:16] <thomasm> what is the semantic difference in the output?
[11:55:21] <jrlevine> they all have to be done, but if you want to compute the hashes before fetching the key, so what?
[11:55:34] <eric> um, yeah. they have to, for example, get the public key before then can compute the verification.
[11:55:36] <Eliot.Lear> does 6.1 also retrieve the selector?
[11:55:50] <eric> no, that's 6.2
[11:56:08] <tonyhansen> 6.1,6.2,6.3 must be done before 6.4,6.5 Parts of 6.2 and 6.3 can be done in parallel 6.4 and 6.5 can be done in either order
[11:56:15] <jrlevine> All that matter are the data dependences, you can't compare a hash you haven't computed yet
[11:56:17] <tonyhansen> 6.6 doesn't fit the list
[11:56:22] <eric> tony: true
[11:56:28] <sftcd> but we don't need to call out all possible orderings, right?
[11:56:46] <eric> i hope not.
[11:56:56] <eric> shall i move 6.6 to 7, and push everything else down?
[11:56:57] <thomasm> a small reality check: has this been a problem with implementations? I don't think so
[11:57:20] <Eliot.Lear> I agree with stephen and mike re 3280. perhaps regroup according to tony?
[11:57:23] <doug_trendmicro@jabber.org> Push down MUA looks good.
[11:57:56] <Eliot.Lear> [this is now issue 1284]
[11:58:13] <sftcd> so if we were to say close this based on 3280-like wording and moving 6.6 down, would that be ok with us all?
[11:58:28] <Eliot.Lear> ok
[11:58:30] <eric> works for me
[11:58:32] <boxley> ok
[11:58:59] <fenton> sounds good
[11:59:01] <sftcd> CLOSE 1284/Issue D - based on 3280-like wording and moving 6.6 down,
[11:59:03] <tonyhansen> no reordering of 6.1 thru 6.5 is needed if you add the "as if" 3280-like wording
[11:59:15] <sftcd> next is issue E - doug's typos
[11:59:23] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003760.html
[11:59:29] <sftcd> (tony - true_
[11:59:33] <fenton> (of course, subject to confirmation on the list)
[11:59:41] <sftcd> as is everything here
[11:59:47] <doug_trendmicro@jabber.org> I added to the list.
[11:59:49] <eric> yeah, i don't know how that happened. i double checked the message i submitted and none of them were there.
[12:00:17] <Eliot.Lear> ok, got to go. ciao
[12:00:20] --- Eliot.Lear has left
[12:00:21] <sftcd> these are all nits, right? so no need to discuss here - eric can make fixes
[12:00:29] <eric> no, i can't.
[12:00:30] <sftcd> that ok?
[12:00:38] <eric> i can't fix something that isn't broken.
[12:00:46] <jrlevine> FTP copy looks fine
[12:00:56] <sftcd> (puzzled expression)
[12:01:09] <tonyhansen> http version is the one with the problems
[12:01:30] <sftcd> so someone should mail ietf-action@ietf.org? volunteers?
[12:01:33] <doug_trendmicro@jabber.org> I was looking at the ietf internet drafts txt document.
[12:01:38] <eric> i got .txt from the rsync server and it was bad.
[12:02:00] <eric> the one with the pointer that doug used was also bad.
[12:02:14] <eric> the one in the message i sent in was good.
[12:02:22] <eric> the version that i put up on the web is good.
[12:02:26] <tonyhansen> ftp version also has the same problem
[12:02:31] <sftcd> volunteer to raise with ietf-action? (maybe the person raising the issue:-)
[12:02:32] <doug_trendmicro@jabber.org> Can't trust TCP.
[12:02:45] <eric> i should take care of this. i'll take it.
[12:02:49] <sftcd> thanks eric
[12:02:59] <dcrocker> Meta: Most IETF efforts leave the details of the writing to the authors, except for critical bits of semantics or specific occurrences that cause contention. Beyond that, the rest of the group reports wording nits to the authors and the authors use them as they see fit. In particular, group time is not consumed discussing these. This is in marked contrast to some other standards groups.
[12:03:26] <tonyhansen> (clarification: problem exists in version at http from ietf.org and ftp from ftp.ietf.org)
[12:03:26] <sftcd> so we close the issue - there';; be a ticket from ietf-action
[12:03:42] <sftcd> Issue E: CLOSE - eric to raise with ietf-actoin
[12:03:57] <sftcd> Issue F: Jim key lookup params
[12:04:07] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003761.html
[12:04:25] <eric> i think i answered this this morning as well.
[12:04:27] <doug_trendmicro@jabber.org> Eric suggested the reason for including the parameter was for future extensions of key servers.
[12:04:35] <eric> correct.
[12:04:54] <thomasm> should we really be trying to guess now though?
[12:05:07] <dcrocker> hmmm. isn't it true that there might be all sorts of extensions, each with different needs?
[12:05:19] <fenton> I couldn't think of an extension that would key off the i= value, just the s= value.
[12:05:28] <thomasm> I can see that that might be really confusing to a implementor
[12:05:32] <eric> jim: per-user keys.
[12:05:33] <dcrocker> in other words, +1 on thomas' point.
[12:05:46] <boxley> for a later doc
[12:05:56] <doug_trendmicro@jabber.org> As the g= must compare against the i= it may not be unreasonable to include this parameter within the lookup function.
[12:06:05] <fenton> eric: per-user keys would still look up based on s= and then compare i= with g=
[12:06:18] <fenton> Maybe I just don't have enough imagination...
[12:06:29] <thomasm> right -- the selector is a pointer to that specificity I thought
[12:06:31] <eric> if you had a selector per user.
[12:06:56] <doug_trendmicro@jabber.org> The lookup function could return no key without indicating why.
[12:07:04] <fenton> Why would a selector per user be a problem?
[12:07:13] <doug_trendmicro@jabber.org> This would meet the goal of not caring about the g= parameter being used.
[12:07:34] <eric> i guess it doesn't need to be. i can think of other ways to do this.
[12:07:52] <eric> ok, it goes.
[12:08:12] <thomasm> good -- extensions can always extend
[12:08:19] <sftcd> so that'd be an ACCEPT for Issue F then
[12:08:43] <sftcd> Issue F: ACCEPT - eric will get rid of i= in relevant places
[12:08:56] <sftcd> timing - we're 10 minutes from 80 but doing ok
[12:09:11] <sftcd> Issue G: Doug, g= template
[12:09:19] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html
[12:09:35] <doug_trendmicro@jabber.org> This was to allow an increase in security related to key restrictions.
[12:09:59] <doug_trendmicro@jabber.org> This was to prohibit the use of sub-domains as well as restrict localparts.
[12:10:25] <sftcd> doug - can you motivate us a bit?
[12:10:53] <doug_trendmicro@jabber.org> A parent could offer assurance by restricting the use of their keys for example.
[12:10:55] <Barry Leiba> I'll try: TOTE that barge! LIFT that bale!
[12:11:20] <doug_trendmicro@jabber.org> The cascade failure of a key can be restricted with this provision.
[12:11:20] <sftcd> :-)
[12:11:48] <sftcd> Barry's motivation is currently working better for me I'm afraid
[12:12:06] <doug_trendmicro@jabber.org> I don't like the idea of parent signing as this may lead to abuse, but this g= extension would provide a means to limit possible damage.
[12:12:14] <boxley> see if I get this straight g=bill*****@cox.com will fail if i=bobknowx@cox.com
[12:12:36] <Barry Leiba> But doug, isn't it the parent who's also defining the key record and putting in the g=?
[12:12:52] <fenton> I see some benefit to this if the parent's key is compromised
[12:12:55] <jrlevine> Let's not have this argument again, please
[12:13:08] <doug_trendmicro@jabber.org> Yes. The current g= parameter is only for localparts.
[12:13:22] <jrlevine> if the parent is compromised, you lose in a thousand ways of which we're about #847
[12:13:41] <Barry Leiba> Right: the only thing to do with a compromised key is to pull it.
[12:13:44] <doug_trendmicro@jabber.org> If the key is compromised this restriction limits the damage.
[12:13:47] <fenton> John: Agree, that's why I said "some" benefit
[12:13:54] <thomasm> for my part, I couldn't agree to a change like this until I really thought long and hard about it as it's all very tricky
[12:13:56] <doug_trendmicro@jabber.org> Compromising DNS is a different issue.
[12:13:57] <Barry Leiba> I understand that we'd like to narrow the window, but it's really infeasible to do that in general.
[12:14:21] <sftcd> mike+1
[12:14:26] <thomasm> I'm very hesitant in making any change to this logic for fear of unintended consequences
[12:14:43] <sftcd> sql-insertion like things even?
[12:14:59] <fenton> I think we need to defer this issue and discuss some more on-list.
[12:15:04] <doug_trendmicro@jabber.org> This can be done later.
[12:15:31] <sftcd> Better to leave this open or close and raise as an extension later?
[12:15:48] <boxley> close, interesting extention
[12:15:49] <eric> it's not really an extension --- it changes the syntax of g=
[12:16:06] <Barry Leiba> Why don't we leave it open so we don't lose it. But we won't hold -base up for it.
[12:16:24] <sftcd> ok - leaving it open for now so
[12:16:42] <sftcd> Issue H - OPEN for now - more thought/discussion needed
[12:16:53] <sftcd> Issue J: Otis, i=
[12:16:59] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html
[12:17:25] <thomasm> did you get the wrong url?
[12:17:31] <sftcd> quite possible
[12:17:32] <doug_trendmicro@jabber.org> Yes.
[12:17:35] <eric> must -- that's the same as the last one.
[12:17:47] <doug_trendmicro@jabber.org> signature removal is next
[12:17:56] <sftcd> oops - who's quicker than me finding the right one?
[12:18:03] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003763.html
[12:18:04] <eric> From: Douglas Otis <dotis@mail-abuse.org> To: IETF-DKIM <ietf-dkim@mipassoc.org> Subject: [ietf-dkim] draft-ietf-dkim-base-02 //i= parameter Date-Sent: May 31, 2006 5:11:55 PM -0700 ,--- |1.2 Signing Identity | | DKIM separates the question of the identity of the signer of the | message from the purported author of the message. In particular, a | signature includes the identity of the signer. Verifiers can use the | signing information to decide how they want to process the message. | | INFORMATIVE RATIONALE: The signing address associated with a DKIM | signature is not required to match a particular header field | because of the broad methods of interpretation by recipient mail | systems, including MUAs. '___ This statement seems in conflict with this statement: ,--- | 5.1 Determine if the Email Should be Signed and by Whom |... | A signer MUST NOT sign an email if it is unwilling to be held | responsible for the message; in particular, the signer SHOULD ensure | that the submitter has a bona fide relationship with the signer and | that the submitter has tthe right to use the address being claimed. '___ Change to: | A signer MUST NOT sign an email if it is unwilling to be held | responsible for the message; in particular, the signer SHOULD ensure | that the submitter has a bona fide relationship with the signer and | that the submitter has the right to use the address when a specific | address is noted in the i= parameter.
[12:18:05] <sftcd> that it?
[12:18:07] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003763.html
[12:18:38] <doug_trendmicro@jabber.org> Okay.
[12:18:54] <eric> i disagree.
[12:19:04] <thomasm> bona fide in a spec makes me cringe
[12:19:05] <doug_trendmicro@jabber.org> Section 5.1 appears poorly worded.
[12:19:11] <sftcd> (Timing - this is our last one today if we're gonna chat about timelines for a few miniutres before the end)
[12:19:27] <eric> by if the i= doesn't have a particular user, you should still make sure that the submitter has a right to use a domain address
[12:19:37] <fenton> I don't like the implication that a signer has to do less diligence if they don't include i=
[12:19:47] <eric> jim: exactly.
[12:19:56] <doug_trendmicro@jabber.org> What if the i= does not match anything in the message?
[12:20:03] <jrlevine> it could use some wordsmithing, but I agree i= isn't the problem
[12:20:04] <doug_trendmicro@jabber.org> What does the i= need to say?
[12:20:20] <doug_trendmicro@jabber.org> What was section 1.2 all about?
[12:20:35] <eric> if you have i=@sendmail.com, the sendmail.com mailer better make sure that the sender has the right to claim to be from someone@sendmail.com.
[12:21:08] <doug_trendmicro@jabber.org> They have a right to have their messages sent from sendmail.com perhaps.
[12:21:26] <doug_trendmicro@jabber.org> The email-address may not include sendmail.com within any header.
[12:21:27] <eric> in which case sendmail.com should be happy to oblige.
[12:21:34] <eric> but if they don't, it should not.
[12:21:39] <jrlevine> I dunno, I'm postmaster@xx for several hundred xx, I might sign as i=postmaster@iecc.com but mail would go out as postmaster@taugh.com
[12:22:16] <dcrocker> are we debating sender signing practises stuff, here?
[12:22:18] <boxley> either a signer will sign or not, anything more gets into reputation scaling
[12:22:22] <eric> as i understand the change, doug is saying that "if you have i=postmaster@iecc.com, then iecc should be careful to verify that the sender has the right tomake that claim,
[12:22:28] <thomasm> that's just what I was going to ask, Dave
[12:22:37] <eric> but "if you have i=@iecc.com, then iecc shoudl just sign anything."
[12:22:59] <doug_trendmicro@jabber.org> Or if there is no i=
[12:23:11] <eric> there is always an i=, even if it is implicit
[12:23:30] <doug_trendmicro@jabber.org> Yes I understand.
[12:23:47] <doug_trendmicro@jabber.org> I was suggesting the definition of signing address soon.
[12:24:06] <sftcd> are we close to consensus here or should we punt to the list?
[12:24:22] <fenton> I'd vote against this change
[12:24:33] <sftcd> (we don't vote though)
[12:24:35] <sftcd> :-)
[12:24:36] <jrlevine> punt, for now
[12:24:51] <dcrocker> defer or deny.
[12:24:56] <fenton> That's why I said "I *would*" :-)
[12:24:59] <doug_trendmicro@jabber.org> defer then;
[12:25:01] <sftcd> Ok - to give ourelves time before the end let's punt on this one
[12:25:17] <sftcd> Issue J: PUNT (to list)
[12:25:23] <sftcd> Ok we into the AOB part of the agenda
[12:25:34] <sftcd> Eric wanted to talk about timing, any other items?
[12:25:46] <sftcd> Eric...
[12:26:19] <doug_trendmicro@jabber.org> There were three other issues not covered on the links you posted.
[12:26:21] <eric> i'll be in a plane somewhere over europe at this time next week.
[12:26:34] <sftcd> (doug - yep, we'll continue next time)
[12:26:51] <sftcd> and Barry and I are awol on the 15th (probably)
[12:26:54] <eric> so i can't attend.
[12:27:02] <eric> not clear that you can't go without me though.
[12:27:21] <eric> i'll just have to miss all the fun.
[12:27:26] <sftcd> well the list still exists, even if this is quicker
[12:27:35] <sftcd> Here's a suggestion:
[12:27:49] <Barry Leiba> (I'm going to cut out now, and try to get lunch to bring to my next meeting, in 2 minutes. Bye...)
[12:28:02] <boxley> by
[12:28:04] --- boxley has left
[12:28:14] <sftcd> We ask people to raise issues on base- up to next week, then try kill those in the following two weeks then start WG LC if we can
[12:28:29] --- dcrocker has left
[12:28:32] <sftcd> That'd be starting WG LC about the end of June
[12:28:44] <thomasm> I think we're pretty close, so that sounds good to me
[12:28:54] --- sm-msk has left
[12:29:06] <eric> ok. if we don't go next week, that gives us no more jabber sessions until after the due date for new drafts.
[12:29:46] <sftcd> I was assuming we do jabber next week - but we may make less progress of course
[12:29:51] <sftcd> Or we can move the day...
[12:29:53] <eric> ok, good.
[12:30:14] <sftcd> Why don't I take an action to send a mail about this to the list?
[12:30:18] <eric> i could do monday 5 june
[12:30:31] <sftcd> most of next week is ok for me
[12:30:39] <eric> after that i'm ok after 15 june
[12:30:44] <jrlevine> ok on 5 june
[12:30:47] <thomasm> calling for consensus earlier on the list might help too Stephen
[12:31:04] <fenton> 5 june ok
[12:31:11] <thomasm> I'm easy too
[12:31:20] <thomasm> (5 june, that is :)
[12:31:28] <sftcd> ok let me craft a mail to the list along those lines and see what happens but it sounds ok
[12:31:47] <sftcd> (June 5 is a holiday here though so you may have to answer to my wife too!)
[12:32:00] <eric> ok for me. i guess this wraps it up....
[12:32:05] <sftcd> Any other topics for our last -2 minutes?
[12:32:07] <sftcd> Nope?
[12:32:12] <sftcd> Bye for now then.
[12:32:17] * sftcd has set the topic to: DKIM meeting done.
[12:32:19] <thomasm> cya
[12:32:24] <fenton> bye
[12:32:25] <doug_trendmicro@jabber.org> bye
[12:32:25] <eric> it's a wrap!
[12:32:26] <eric> bye
[12:32:30] --- fenton has left
[12:32:30] --- doug_trendmicro@jabber.org has left
[12:33:21] --- jrlevine has left
[12:34:22] --- sftcd has left
[12:34:36] --- thomasm has left
[12:36:02] --- Dennis Dayman has left
[13:18:25] --- tonyhansen has left
[13:33:24] --- Barry Leiba has left
[13:36:18] --- dcrocker has joined
[14:01:14] --- dcrocker has left
[15:35:47] --- dcrocker has joined
[15:53:19] --- dcrocker has left
[16:26:05] --- eric has left
[16:39:39] --- dcrocker has joined
[17:27:44] --- dcrocker has left
[17:55:00] --- dcrocker has joined
[18:03:17] --- dcrocker has left
[18:57:08] --- wildcat has joined
[19:00:06] --- wildcat has left
[22:15:33] --- dcrocker has joined