[12:39:13] --- randal has joined
[12:40:20] <randal> Ahhh, the new version of Nitro finally fixed my connection problems!
[12:58:30] <randal> tap tap tap...is this thing on?
[12:59:46] --- mengwong has joined
[13:02:24] --- randal has left
[13:03:52] --- mrose has joined
[13:04:50] --- mrose has left
[13:14:48] --- rand@sendmail.com has joined
[13:44:19] --- rand@sendmail.com has left
[14:11:00] --- dcrocker has joined
[14:49:15] --- mrose has joined
[14:49:32] <dcrocker> marshall - is there an agenda?
[14:49:44] --- resnick has joined
[14:49:48] <mrose> for today, not really.
[14:49:56] <dcrocker> ok. tnx.
[14:50:03] <mrose> the ietf60 meeting is next week. today's meeting is just to see what folks want to talk about before then, if anything...
[14:51:44] <mrose> anyone want to talk about anything?
[14:52:21] <dcrocker> the list seems to be getting quite a bit of "let's do original SPF rather than Sender-ID".
[14:52:52] --- SamSilberman has joined
[14:55:45] <mrose> meng?
[14:57:16] --- mtnviewmark has joined
[14:58:27] <mtnviewmark> mark is here
[14:58:45] <mrose> mark - can you address crocker's perception?
[14:59:12] <mtnviewmark> well, I see two threads on the list
[14:59:49] <mtnviewmark> 1) I see concern that MTAs shouldn't be looking "inside" messages, etc...
[15:00:22] <mtnviewmark> 2) I see concern that the PRA algorithm is not-tested, and/or not-understood, and/or not-pick-something-you-don't-like abotu it
[15:01:02] <mtnviewmark> There is also the thread of intellectual property: "If PRA is going to be encumbered, then let's do MAIL-FROM"
[15:01:28] <mtnviewmark> To take these in reverse:
[15:01:53] <mtnviewmark> I don't think there is anything to say about the intellectual property issues or concerns until we get more information
[15:02:18] <mtnviewmark> 2) The current state of the PRA algorithm, as in core-02, is basically the RFC 2822 definition of who injected the mail
[15:02:37] <mtnviewmark> mind you, RFC 2822 doesn't make any such definition
[15:03:01] <mtnviewmark> but that is probably because it didn't need to think in those terms
[15:03:22] * resnick nods
[15:03:46] <mtnviewmark> I don't see any specific technical concerns on the list in this catgory
[15:04:12] <resnick> ...and also because "injecting into the transport system" is 2821's problem, not 2822's.
[15:04:48] <mtnviewmark> I suppose the only outstanding issue here is just the due dilligence to make sure that in current practice, the headers defined in RFC 2822 and used in PRA are actually used as intended
[15:05:37] <mtnviewmark> resnick: Right, though, alas, 2821 skirted keeping track of that information, and 2822 did (via the Resent-* headers)... so logical or not, the info is in 2822, not 2821
[15:06:18] <resnick> Anecdotal answer re current practice: I don't believe Resent-* consistently are. Sender is sometimes, but not always.
[15:06:22] <dcrocker> mark - the question i raised was not about technical issues. the points you are making are excellent for the technical discussion(s) that
[15:06:34] <mtnviewmark> ah, okay...
[15:06:46] <dcrocker> should happen. however the point i was raising was my perception about a pretty serious division of support. /
[15:08:03] <mtnviewmark> Ah, well, I worry about this too, but I'm not a good judge of it: How strong was the lists commitment to PRA (or any 2822 header based approach) back in Spring? Is the new wave of concern mostly coming from new people to the list?
[15:08:21] <mtnviewmark> Is it mostly just people who dissented from the general agreement?
[15:09:27] <dcrocker> those are reasonble questions, certainly. however i view the consensus issue as ultimately hinging on the ability to get community
[15:09:49] <dcrocker> adoption of the working group's output. whether people are new or not, the question to me is whether they represent a larger
[15:10:07] <dcrocker> community division that could be problematic for use of the working group's output. whereas i
[15:10:29] <dcrocker> think that clean competition among truly alternative approaches can be a good thing, i think that division WITHIN a supposed
[15:10:35] <dcrocker> community can kill it./
[15:12:20] <mtnviewmark> There is a fair bit of momentum behind the original SPF -- but it is because it is "something to do", rather than "it's right - MARID is wrong".
[15:13:40] <mtnviewmark> I think that if we recognize and explain MARID's work as an evolution of ideas including original SPF, and if we recognize that the community wants to be doing something - then they will come along with us once they perceive MARID as doing
[15:14:58] <mtnviewmark> I think the community doesn't want to have its existing momentum diminished
[15:15:00] <mtnviewmark> /
[15:15:25] <dcrocker> (I left out the additional pull that I suspect is greated by the non-marid "unified spf" references. i can't tell what effect that
[15:15:40] <mengwong> i have explanations prepared that show how the Sender ID approach of checking PRA-SUBMITTER and falling back to MAIL-FROM are actually very very close to the spirit of SPF Classic, so converting that community will not be that hard.
[15:15:59] <dcrocker> has on the marid work, but it seems like it OUGHT to be distracting. in any event, mark, your view makes sense except that I haven't seen
[15:16:29] <dcrocker> it being pursued on the list, to resolve the apparent tension. so, how, when will this apparent lack of consensus get fixed?/
[15:16:36] <mengwong> the main obstacle seems to be the licensing concern: if a GPL'ed MTA is unable to distribute Sender ID technology, the opensource/free software community will feel excluded.
[15:17:14] <mengwong> once the licensing concerns are resolved, I am confident that the calls to do SPF Classic will subside.
[15:17:51] <mtnviewmark> Well, I feel that Meng's and my Unified SPF work was for the original SPF community a major step in showing that the current MARID work is all part of a continuum of from where we started with SPF.
[15:19:06] <mrose> all - i have to handle something, i'll be back in 10.
[15:19:14] <mtnviewmark> I'm sorry if you feel that Unified SPF has left more questions on the list than it answered. I do note, though that it seems to have a doppleganger (sp.) in the form of H. Santos' ideas
[15:20:53] <mtnviewmark> i do agree with Meng, that at least from the original SPF community, once the licensing issues is resolved, then they will be there with us. I also sense, alas, that that issue is going to domniate until it is resolved.
[15:22:38] <dcrocker> 1. with respect to Unified SPF, my reason for concern is very simple: it is an alternate set of documents and they are
[15:22:57] <dcrocker> outside the ietf marid working group and they are constantly cited. this can and does leave
[15:23:24] <dcrocker> quite a bit of confusion about the current standards work and its direction.
[15:23:35] <dcrocker> 2. if the view on cohesiveness is that
[15:24:24] <dcrocker> everything hinges on the IPR, then it suggests that no serious work can get done until that is resolved, at some unknown, later time. otherwise, all work on sender-id/spf will be based on suppositions that have no assurance of being valid./
[15:24:29] <mtnviewmark> (A quick check shows me that the Unified SPF documents were only referenced once in the last three weeks on the mailing list)
[15:25:15] <mtnviewmark> I have had no personal communications from any one on the unified drafts in the last three weeks, whereas I've received corrections and suggestions
[15:25:30] <mtnviewmark> for the official draft-ietf-marid-protocol-00 document
[15:25:53] <mtnviewmark> So, I don't think there is much confusion in the wild about which are the current documents to be concerned with
[15:25:59] <dcrocker> ok. so your view is that there is no marid problem with respect to unified spf. fine.
[15:27:01] <mtnviewmark> I agree with your general assessment about the IPR and work. However, the protocol document is not subject to any IPR issues, and so it can be refined.
[15:27:15] <mtnviewmark> And, to a major degree, so can the SUBMITTER document.
[15:27:31] <dcrocker> huh?
[15:28:05] <mtnviewmark> If you look carefully at the protocol document, it doesn't reference PRA at all, or the Sender-ID draft in any normative manner
[15:28:51] <mtnviewmark> It specifies a record format, and the proper way to check an IP address against a mailbox's domain.
[15:29:40] <mtnviewmark> We can refine it and get it right, while the other issues are being resolved, cognizant that it's use will hinge on those outcomes
[15:29:49] <mtnviewmark> But, we can work on the technical aspects of it.
[15:30:41] <mtnviewmark> I'd like to know, if the IPR issues resulted that there was no community support for PRA, what would you suggest we do? Fall back to MAIL-FROM? Switch core to just use From: header?
[15:30:49] <mtnviewmark> Abandon the whole idea? /
[15:31:32] <dcrocker> I'm pretty much the last person to ask about what to do to bring spf/sender-id to a productive conclusion. I'm just a tad invested in a
[15:31:52] <dcrocker> different line of effort and have been a tad to vocal about fundamental problems with SPF. However
[15:32:23] <dcrocker> I felt obligated to raise a group process concern I was seeing, so that those of you actively pursuing the spf/sender-id spec would consider it./
[15:33:14] <mtnviewmark> Well, I don't see this as "Thunderdome: Two ideas walk in, One idea walks out...", So I'm glad for your input.
[15:35:58] <dcrocker> anything else for us to talk about today?
[15:36:11] <mrose> anyone?
[15:36:35] <mrose> going once.
[15:36:44] <mengwong> er, the schedule for wednesday?
[15:36:52] <mengwong> it is wednesday, right?
[15:37:00] <mrose> an agenda was sent to the mailing list. it is wednesday, two sessions:
[15:37:07] <mengwong> i was planning to fly in tuesday night and fly out thursday night.
[15:37:14] <mtnviewmark> NEXT wednesday...
[15:37:18] <mtnviewmark> :-)
[15:37:27] <mrose> From: mrose@dbc.mtview.ca.us Subject: MARID agenda for IETF60 Date: July 21, 2004 19:06:42 PDT To: ietf-mxcomp@imc.org Cc: andy@hxr.us Wednesday, August 4 2004 0900-1130 1. Agenda bashing 2. Review and discussion of draft-ietf-marid-submitter-02 3. Review and discussion of draft-ietf-marid-protocol-00 - semantics and backwards-compatibility Wednesday, August 4 2004 1530-1730 4. Intellectual property discussion 5. Review and discussion of draft-ietf-marid-core-02 - PRA algorithm refinement 6. Discuss milestones for CSV series of documents #######
[15:37:49] <mengwong> excellent.
[15:37:52] <mrose> going twice.
[15:38:33] <mrose> done.
[15:38:42] <mrose> thanks very much. see everyone in san diego or on the chat room...
[15:38:43] --- mrose has left
[15:38:46] <dcrocker> bye
[15:38:49] --- resnick has left
[15:39:21] <mtnviewmark> bye
[15:39:33] --- mtnviewmark has left
[15:41:24] --- SamSilberman has left
[15:54:48] --- mengwong has left: Disconnected
[18:38:24] --- LOGGING STARTED