[12:54:48] Barry Leiba joins the room [13:04:38] SSILBERMANWS1 joins the room [13:15:50] =JeffH joins the room [13:17:50] cute [13:17:53] tonyhansen joins the room [13:17:55] Alessandro Vesely joins the room [13:18:00] Hi [13:18:18] I also heard the joke from eariler [13:18:24] <=JeffH> did u ? [13:19:51] aka joins the room [13:22:17] sm joins the room [13:25:53] https://datatracker.ietf.org/meeting/78/materials.html [13:26:54] Randall Gellens joins the room [13:28:26] mccap joins the room [13:33:50] yes [13:37:03] resnick joins the room [13:37:47] Is someone jabber scribing? I'm not in the room. [13:38:08] Tony is taking minutes, but not into jabber. [13:38:26] Tony, can you take your notes over here? [13:39:51] :( [13:40:58] was doing minutes, but not real time notes [13:44:03] randy     use of DNS txt records was controversial     should not continue kludge of txt records [13:45:04] dave crocker txt records have issues ? disables use of wild cards issue of resource record raised every time one is needed, with claims that it's fixed, but no existence proof that they are fixed [13:45:42] murray dkim could switch to srv jd discovery could use srv, since not tied to dkim [13:46:24] barry wg needs to give more comments on these two docs do we adopt into the WG? murray docs will probably be merged [13:49:08] murray OMA working on spamrep enabler client and server for exchanging abuse reports transport is HTTP post security (HTTPS) is out of scope report is xml based supports repoting about sms, mms, im, email [13:49:32] cyrus joins the room [13:49:50] myidiym joins the room [13:51:17] testing... am I now finally in the room? [13:51:29] You are. [13:51:37] FYI, this is Brett McDowell [13:51:43] murray spamrep also defines response format, plus a way to ask status of previous report on edge of OMA's equivalent to IETF LC defines new mime type for xml piece marf is chartered to remain parallel to oma work and not step on each other [13:51:43] Hey, Brett. [13:51:57] You hearing the audio OK? [13:52:20] regarding the scribe question that came up earlier (I'm also listening to the audio stream) the IETF website says: Each working group session at IETF 78 has an associated chatroom that is open during the meeting. The session scribe will type a running commentary as to what is going on in the room. During question time, remote participants can type questions into the chatroom and the scribe will pass the question along to the speaker. [13:52:28] murray he is trying to facilitate knowledge exchange, as IETF liaison to OMA [13:52:28] yes, the audio is awesome actually [13:53:26] Brett, there should be a couple "MAY"s in that statement :-) [13:53:39] :-) [13:55:53] yigang cai from alcatel/lucent see slides on the web site https://datatracker.ietf.org/meeting/78/materials.html#wg-marf [14:01:33] =JeffH leaves the room [14:03:49] =JeffH joins the room [14:08:59] murray: does smaprep already cover all this already alex: protocol id is not murray: oma can probably get the missing pieces added can ARF carry a spamrep payload? alexey: what's registration policy for new fields? various: expert review best option [14:09:28] barry: policy is currently specified as "specification required" [14:10:37] murray/alexey/tony: discussion about multipart/report [14:10:48] a few people, including Murray, seem to be too close to their mic... it's starting to distort [14:11:54] alex bobotek see slides at https://datatracker.ietf.org/meeting/78/materials.html#wg-marf [14:14:04] is Tony the OMA rep. to IETF (the mirror of Murray's role)? [14:14:47] No, he's not. [14:14:54] thnx [14:15:44] There is an OMA liaison to the IETF, but she doesn't work with SpamRep directly. Alex (who's speaking now) is our contact in SpamRep, and Murray's working diligently with the group. [14:16:25] ah, yes, sorry... I meant "Alex" (not Tony). Thanks for the context. [14:19:29] when the time is right, I'd like to ask Alex why OMA made SpamRep attributes non-extensible. [14:21:26] I'll channel when he's done presenting. [14:21:47] thnx [14:24:19] brett (channel): why are attributes non-extensible alex: mistake [14:24:23] Hi Dave [14:24:27] ;-) [14:24:34] alexey: use mutipart/digest could include multipart/report [14:24:48] alex: disagrees with multipart/report must be top level [14:26:16] dave: needs real clarification of 3462 [14:27:41] dave: 1 spec across orgs is good idea [14:27:44] I agree with Dave's point... get both groups to agree to the premise that there will be only one spec, then figure out who/how later. [14:28:53] dave: gatewaying is bad likes alex' side by side vis-a-vis [14:29:34] barry/murray: xml difficult, particularly w/ base of code [14:30:35] dave: can define upgrade path, [14:30:56] murray: marf is not smtp only [14:32:57] tony/cyrus: comments about top level use of multipart/report [14:36:12] randy: in smtp pipeline multiple reports ? what transport makes sense for reports doug: does transport have compression layer we're not aware of? randy: compression is also defined tls, or smtp/imap extensions [14:36:32] back to slides [14:38:10] barry: does aspects in spec require structure [14:38:25] With HTTP POST, you would have to wait for one report to complete before sending another, hence one report per message would increase round-trips. By contrast, using SMTP allows each report to be pipelined and hence no increase in round trips [14:38:45] Compression can be enabled with either HTTP or SMTP via TLS [14:39:59] HTTP supports pipelining. [14:40:40] However, aside from data size, each request does have a cost in terms of authentication etc on the server-side which is also a concern. [14:43:40] (Actually I could be wrong about piplelining with POST as opposed to other methods ... need to double-check that) [14:46:28] aka leaves the room [14:47:06] who drove the requirements for ARF, and who is driving the requirements for SpamRep (generally speaking)? [14:47:10] Low volume ARF receivers are far less likely to have automated parsers. I envision as MARF becomes more popular, we will see more and more new low volume adopters who will not need automation. If they can’t read the reports, they will not find them useful and opt-out. [14:47:56] alex: xml vs. name/value pairs dave: a habit: thinking name/value pairs but values are often with structure but name/value pairs are stupid for things that really need structure verbosity: it's not the names that are really verbose, but the values barry: used to hear that xml is slow, but not really true jd: name/value pairs, consumers are often people, not machine dave: users should not be seeing this! jd: it's a bad idea, but happens a lot jd: there are a dozen arf generators, but a thousand consumers jd: spamrep looks like it's less between marketers, but telcos alex: spamrep has not grown from those at abuse desks murray: spamrep looks like it was based on early versions of arf, further evidence of no installed base feedback barry: aim of arf is to be server to server, different focus jd: use cases are overlapping, but different, could get away with having a fork to marf to allow xml [14:48:48] barry channels brett jd: arf reqts came from maawg, spamrep came from oma wg (operators & device manufactors) [14:49:17] So ARF was driven by ISP's primarily, SpamRep was driven by Operators primarily... that's what I think JD and Alex just said, yes? [14:49:22] barry channels sam jd: many of the thousand consumers are low volume [14:49:37] Brett: yes [14:49:41] thnx [14:50:24] nathaniel: these old formats from long ago are a pain but we're stuck with them for old things, but we don't need to use them for future work [14:50:57] cyrus: can xml be constrained? (no attributes in xml objects) [14:51:10] alex: (on to slide 9) [14:54:27] yigang: alcatel-lucent has customers that can use the attributes. they're needed [14:54:53] doug: his company's reports also use report ids and such -- important [14:55:18] jd: some report generators could also use report id and reporter id, but should be optional [14:55:20] I see a Convergence Roadmap on slides 11-12, but that only lists the features to change, not the process for coordinating changes. What is the process for coordination between ARF and SpamRep... how are we pursuing convergence at this point? [14:56:12] jd: report id because it's not there right now, reporter id because of privacy concerns [14:56:25] resnick leaves the room [14:56:48] resnick joins the room [14:57:22] sm leaves the room [14:58:27] alex: skipping appendices murray: current spec is public, so will send pointer to list there are issues with spamrep dates [14:58:48] debates on mime type can be on list [14:59:21] my question in the chat room [14:59:28] bye [14:59:33] barry: wg should consider xml payload, and migration to it [15:00:21] aka joins the room [15:00:28] yes [15:00:41] resnick leaves the room [15:00:43] bye [15:00:44] myidiym leaves the room [15:00:48] Barry Leiba leaves the room [15:01:28] mccap leaves the room: Computer went to sleep [15:04:22] aka leaves the room [15:04:41] Alessandro Vesely leaves the room [15:10:23] Randall Gellens leaves the room [15:11:15] =JeffH leaves the room [15:11:37] cyrus leaves the room [15:15:02] mccap joins the room [15:15:12] tonyhansen leaves the room [15:19:14] mccap leaves the room [15:24:34] sm joins the room [15:24:37] sm leaves the room [15:35:37] =JeffH joins the room [15:38:42] =JeffH leaves the room [21:19:18] SSILBERMANWS1 leaves the room