[08:38:30] --- Minneapolis has joined
[08:46:41] --- ogm has joined
[08:46:46] --- Minneapolis has left
[08:46:48] --- ogm has left
[08:48:39] --- bew has joined
[08:54:04] --- johan.liseborn has joined
[08:54:31] --- jean-francois has joined
[08:56:02] --- xiaohunhun has joined
[08:56:20] --- kanda has joined
[08:57:51] --- jfb has joined
[08:58:08] --- tfroment has joined
[08:59:33] <tfroment> is there a jabber scribe?
[09:00:04] --- don_g has joined
[09:00:19] --- Minneapolis has joined
[09:01:09] --- eburger has joined
[09:01:22] <eburger> JUST got here. Sorry
[09:01:38] <eburger> Robert mentioned registration for SIPIT 16 closes next week.
[09:01:52] <eburger> P2P Ad Hoc 10pm tonight, room TBD
[09:02:02] <eburger> Robert asks for review of dialog draft
[09:02:41] <eburger> Q: Hasn't location requirements moved to SIP? A: Yes. Will remove from SIPPING milestones
[09:02:58] <eburger> please review sip-sec-flows draft
[09:03:25] <eburger> Next Up: Dan Petire on Configuration Framework and Data Sets (draft-ietf-sipping-config-framework-06)
[09:03:53] <eburger> Describes changes (see slides)
[09:04:06] <tfroment> http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-06.txt http://scm.sipfoundry.org/rep/ietf-drafts/petrie/profile-data-sets/draft-petrie-sipping-profile-datasets-01.txt
[09:04:40] <eburger> Draft describes how to negotiate schemes other than HTTP & HTTPS; follows app-interaction model.
[09:05:04] --- johan.liseborn has left: Disconnected
[09:05:11] <eburger> List Issues Discussion
[09:06:39] --- ogm has joined
[09:06:41] --- eburger has left: Replaced by new connection
[09:06:41] --- eburger has joined
[09:06:41] --- eburger has left
[09:06:50] --- eburger has joined
[09:06:59] <eburger> Aargh - I hate wireless today!
[09:07:04] <tfroment> :)
[09:07:28] <eburger> Anyway - does anyone care about event type names? event parameters? vendor/model? If so, tell Dan.
[09:08:08] <eburger> Will have more examples, more developed security considerations section.
[09:08:45] <eburger> Will disambiguate what is meant by "cache"
[09:08:55] <eburger> What to do about XCAP section?
[09:09:12] <eburger> (1) kill it (my favorite option for XCAP) ;-)
[09:09:20] <eburger> (2) Define it better
[09:09:51] <eburger> Anyone in the Jabber audience have an inclination?
[09:09:59] <eburger> Does anyone care?
[09:10:16] <eburger> About 30% of folks read -06 draft.
[09:10:44] <eburger> jdr: section needs to be correct, or removed
[09:10:54] <eburger> his inclination is to fix it (option 2)
[09:12:38] <eburger> Dan & jdr will go off and work on it.
[09:12:43] --- kanda has left
[09:12:53] <eburger> Cullen: Security as defined will ONLY work for HTTP/S
[09:13:20] <eburger> No one responded to Cullen's 2-page security e-mail
[09:13:48] <eburger> Some protocols require username/password for access; that isn't carried in SIP/XCAP
[09:14:29] <eburger> Cullen: either say, "Can't use other protocols" or "Put support in framework to support other protocols."
[09:14:42] <eburger> Dan: Offers to only support HTTP/S
[09:14:49] <eburger> Any objections from the JABBER audience?
[09:16:25] <eburger> jdr: no framework for negotiation -- oops, it is in app-interactoin
[09:16:43] <eburger> via content indiraction
[09:16:59] --- xiaohunhun has left
[09:17:03] <eburger> Cullen: Do we want it to work for protocols other than HTTP/S
[09:17:23] <eburger> We can make it work, if we want to.
[09:17:32] --- tfroment has left: Disconnected
[09:18:09] <eburger> Consensus: only HTTP/S, unless someone volunteers to fix framework for other protocols.
[09:18:12] --- tfroment has joined
[09:19:04] <eburger> Scott lawrence: offering sample frameworks (PingTel)
[09:19:07] <eburger> Dan Petrie on Schema for SIP Profile Data Sets
[09:20:18] <eburger> describes changes from -00 (see slides)
[09:21:21] --- tfroment has left: Replaced by new connection
[09:21:37] --- tfroment has joined
[09:21:44] <eburger> Discuss property values (must use, can't use in combination, etc.)
[09:22:02] <eburger> Mostly around merging data sets
[09:22:26] <eburger> General Requirements slide
[09:23:55] <eburger> Proposal for solving constraint/merge problem
[09:25:50] <eburger> Any feedback on proposal?
[09:26:02] <eburger> 15% read draft
[09:26:46] <eburger> Thumb right/wrong : Mostly positive; few neutral
[09:27:26] <eburger> Brijesh Kumar (Panasonic): looks like some use cases won't work, but this draft, and the merging clarification, are REALLY good.
[09:28:43] <eburger> Paul Kizviat: Won't this be the default content type? But that is a long way away.
[09:28:50] <eburger> Can framework proceed w/o default content type?
[09:29:06] <eburger> Rohan: Framework can proceed, as it is useful.
[09:29:12] <eburger> Paul: won't this violate 3265?
[09:29:21] <eburger> Rohan: Still useful, anyway
[09:29:30] <eburger> Paul: won't violating 3265 block publication?
[09:29:52] <eburger> Rohan: draft does describe how to negotiate content type, so draft is OK
[09:29:56] --- Bernie has joined
[09:30:28] <eburger> Volker Hilt: If one policy says "mandatory" and one says "not allowed", looks like call will fail, as irreconcilable rule conflict
[09:30:59] <eburger> Dan: Clearly one can create profiles with conflicts. Idea is that profile with "higher" level in heirarchy wins.
[09:32:14] <eburger> Eunsoo Shim (NEC): wouldn't it be easier to work bottom-up? Lower-level heirarchy is closer to device.
[09:32:24] <eburger> Dan: Lower-level heirarchy has less trust
[09:32:31] --- Bernie has left
[09:33:07] --- bhoeneis has joined
[09:33:54] <eburger> Eunsoo: if you know data is trusted, you should be able to use it
[09:34:42] <eburger> Cullen: You have to decide to use data or not. If you do decide to use it, and there is a conflict, you are hosed. Game over.
[09:35:07] <eburger> Cullen: Agrees that Paul is raising an important issue; let's get this done & finished.
[09:35:52] <eburger> Eunsoo: Asks about how vendors can add local properties.
[09:36:20] <eburger> Dan: This draft is framework, only; follow-on drafts will describe "core" properties; extensible for vendor properties.
[09:36:46] <eburger> New Topic: Voker Hilt on Session-Independent Policies (session-indep-policies)
[09:36:51] <eburger> Status slide
[09:37:49] <eburger> ~7 people read draft
[09:38:27] <tfroment> http://www.softarmor.com/sipping/meets/ietf62/slides/pres-hilt-sipping-session-policy-ietf62.ppt
[09:38:35] <tfroment> (slides)
[09:38:56] --- xiaohunhun has joined
[09:39:07] <eburger> Adam Roach: Amount of pages in drafts exceeds good novels. People would rather read good novels :)
[09:39:20] <tfroment> http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-indep-policy-02.txt, and http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy-02.txt
[09:39:53] <eburger> Rohan: drafts are listed in priority order
[09:40:13] <eburger> Adam: What if we just work on 3 drafts, ONLY
[09:40:44] --- bert has joined
[09:40:57] <eburger> Jon P: these drafts were very controversial. Now that things have settled down, not surprised few people looked at 3rd revision of draft.
[09:41:40] <eburger> Gonzallo: if too much work, need to reduce work.
[09:42:48] <eburger> Most folks look to see if something blatently wrong. If not too bad, then gets less attention.
[09:43:49] <eburger> Cullen: Interim Meetings suck as a solution to keeping up with reading drafts.
[09:44:01] <tfroment> note! all drafts are updated too shortly before the meeting, this is a lot of work to read all the drafts in a short period of time
[09:44:06] <eburger> AND NOW, BACK TO THE TOPIC AT HAND: Session-Independent Policies
[09:44:54] <eburger> BSPF slide
[09:46:13] <eburger> Eunsoo: Differences between session-independent policy and Profile?
[09:46:20] <eburger> Volker: well, they are similar.
[09:46:36] <eburger> Looking to use same data format.
[09:48:06] <eburger> Dave O: Lots of things in schema are things that are already in registries.
[09:48:35] <eburger> Probably want to look for things such that if schema has IANA registered items, then just import registry from IANA
[09:49:20] <eburger> Manish Jani (Cisco): Where do we draw line between XCON policies and SIPPING policies?
[09:49:28] <eburger> Volker: thinks they are different
[09:49:34] <eburger> Cullent: thinks they are not
[09:49:45] <eburger> Manish: Many of these *are* common
[09:50:12] <eburger> jdr: XCON policies would leverage SIPPING policies
[09:51:48] <eburger> John Elwell: Will session-independent policy normatively depend on Data Set document?
[09:52:11] <eburger> Volker: parallel data sets, but not same (?)
[09:52:51] <eburger> can receive policies & data sets from different sources
[09:53:17] <eburger> goal is to align both drafts, so there will be just a single parser, etc.
[09:53:39] <eburger> John: policies can come from local network
[09:53:47] <eburger> Volker: comes from local network
[09:54:25] <eburger> Cullen: His expectation was that these documents came ONLY from configuration profile.
[09:55:05] <eburger> outbound proxy, media intermediaries probably don't belong in this profile
[09:55:07] <eburger> (CullenO
[09:55:35] --- tfroment has left: Replaced by new connection
[09:55:56] <eburger> jdr: things with practical use cases belong; etc.
[09:56:24] <eburger> If no use case, then should not have property in data set
[09:56:25] --- tfroment has joined
[09:56:41] <eburger> Eunsoo: are elements extensible? good if so.
[09:57:15] --- tfroment has left
[09:57:49] <eburger> Dan P: Where does policy stuff go? Local network profile is for policy. However, could specify policies in other profiles.
[09:58:12] <eburger> jdr: this is why people are getting confused between this draft and Data Profile draft.
[09:58:44] <eburger> jdr: all we're doing is defining data sets; where they go is an implementation thing
[09:59:01] --- tfroment has joined
[09:59:19] <eburger> Medavi: do you need a transcoder/b2bua in profile?
[09:59:44] <eburger> Open Issue #2: how do deal with conflicts? Dan addresesd this already.
[10:01:06] <eburger> Status slide
[10:01:52] <eburger> Policy Channel Protocol Open issue slide
[10:05:25] --- eburger has left: Replaced by new connection
[10:05:28] --- eburger has joined
[10:05:29] --- eburger has left
[10:05:37] --- eburger has joined
[10:05:41] <eburger> Sorry for the disconnect:
[10:05:44] --- eburger has left
[10:06:22] --- eburger has joined
[10:06:38] <eburger> Cullen: leans towards SIP SUBSCRIBE/NOTIFY
[10:06:45] <eburger> jdr (jokingly): offers Corba
[10:07:23] <eburger> Should look at what we want to do to pick communication profile
[10:07:42] <eburger> Client is asking "can I do this" and server is asking "no, you should do that"
[10:07:51] <eburger> That doesn't fit into subscribe/notify semantics
[10:08:14] <eburger> Volker: You are giving your policies as a filter; update (notify) from server
[10:08:38] <eburger> Rohan: kind of ok to use notify, but would need different content-disposition
[10:08:44] <eburger> Eric, jdr, Cullen groan
[10:09:55] <eburger> Rohan doesn't have problem with #1, as long as we don't use content-disposition: sessoin
[10:10:44] <eburger> Cullen: need to offer hints from client, as that helps server pick what policy to send down
[10:10:53] <eburger> jdr: some policies are static, per-user
[10:11:09] <eburger> sub/notify good for static stuff
[10:12:29] <eburger> BUT, if we're looking at per-session stuff, like "can I use these codecs", and the server goes off and makes complex, bizarre computations to figure that out, and decisions based on computatoins and data not available to UAC, then will probably get a different answer for the protocol to use to transport policies.
[10:13:22] <eburger> Tom Taylor: leans towards sub/notify, as it is more aligned to filtering / policies get sent up
[10:14:02] <eburger> Paul: do we need to optimize session independent policies? one is much more optimized than the other
[10:14:41] <eburger> Jon: Example to justify session-dependent policies: Preemption, network congestion, etc.
[10:15:06] <eburger> E.g., You're using too much bandwidth. Please change -- that leans towards NOTIFY (asynchronous)
[10:15:20] <eburger> jdr: CAC clearly isn't static
[10:16:11] <eburger> Volker: use cases in document describe issue
[10:16:23] --- xiaohunhun has left
[10:16:27] <eburger> jdr: use cases are data centric, not "what is the question" centric
[10:17:07] <eburger> What are the high-level CAC questions being asked?
[10:18:10] <eburger> Other Issues slide.
[10:18:12] <eburger> Volker: what are next steps?
[10:18:22] <eburger> Gonzallo: Need to discuss off-line
[10:18:56] <eburger> NEW TOPIC: Consent-Based Communictions (consent-reqs-00): Gonzalo Camarillo
[10:19:26] <eburger> Requirements slide
[10:19:54] <eburger> Translation Identification slide
[10:20:26] <eburger> Using Request-URI example slide
[10:20:41] <tfroment> slides: http://www.softarmor.com/sipping/meets/ietf62/slides/pres-ietf62-sipping-camarillo-consent.ppt
[10:21:24] <tfroment> drafts: http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-reqs-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-framework-01.txt
[10:23:31] <eburger> Using Header Field slide
[10:25:21] <eburger> Comparison Slide
[10:26:08] <eburger> Comments on approaches?
[10:27:47] --- eburger has left: Replaced by new connection
[10:27:48] --- eburger has joined
[10:27:48] --- eburger has left
[10:28:00] --- eburger has joined
[10:28:05] <eburger> aaargh!
[10:28:32] --- ogm has left
[10:29:48] <eburger> Permission Upload slide
[10:30:08] <eburger> Jon P: SIP Publish? Isn't there a read option?
[10:30:19] <eburger> Gonz: Proposed to use w/ Subscribe
[10:30:29] <eburger> Jon: wouldn't that fix Publish problem?
[10:30:31] <eburger> Gonz: yes
[10:30:47] <eburger> Henning: looks awfully similar to configuration
[10:31:07] <eburger> Can we use something similar?
[10:31:21] <eburger> Gonz: could use sub/not
[10:32:14] <eburger> Markus Isomaki: If you have multiple permissions, could you aggregate them into a single request?
[10:32:21] <eburger> Gonz: today, different Publish'es
[10:33:04] --- tfroment has left: Replaced by new connection
[10:33:54] --- tfroment has joined
[10:33:55] <eburger> Rohan: support hybrid model
[10:34:12] <eburger> for UA to provide opt-in/out for a single request: PUBLISH works
[10:35:14] <eburger> But like idea of bulk XCAP type stuff
[10:35:20] <eburger> PUBLISH would be "must implement"
[10:35:20] --- fluffy has joined
[10:35:32] <eburger> jdr: Hey - if there is one must implement, only that will get done
[10:35:56] <eburger> jdr: PUBLISH assumes server can sensibly compose permissions
[10:36:40] <eburger> jdr: takes away possibility of heirarchial buddy lists; only works if flat
[10:39:31] <eburger> Dean: people need to know there isn't a single, central repository of consent information
[10:39:39] <eburger> These things get composited on the fly
[10:39:57] <eburger> jdr: true for all models
[10:40:39] <eburger> Rohan: doesn't want to use publish for buddy list management; doesn't work for heirarchical lists
[10:41:08] <eburger> Rohan: jdr noted lots of stuff you can't do if we chose PUBLISH.
[10:41:11] <fluffy> wow - this is more people that I have ever seen in a sip jabber room
[10:41:22] <eburger> Rohan: And this is why we should use PUBLISH :)
[10:41:31] <eburger> Dave O: is the idea to REVOKE consent?
[10:41:49] <eburger> How can you revoke consent without holding state?
[10:41:55] <eburger> You may need to hold state to know where to go to withold consent.
[10:42:00] <eburger> Gonz: yes.
[10:42:14] <eburger> Miguel: if you change terminals, what happens
[10:42:21] <eburger> Gonz: stuff comes with each request
[10:42:48] <eburger> Dean: Like mail list, where every message includes X-Unsubscribe
[10:43:10] <eburger> Paul: Looks like we need to do CONSENT for REGISTRATION; unlikely to use XCAP for that.
[10:43:28] <eburger> Jon P: correlation between registration and permission upload
[10:43:49] --- bew has left: Replaced by new connection
[10:43:50] --- bew has joined
[10:43:50] --- bew has left
[10:43:59] <eburger> Jon P: model of passing token around is different than mail list.
[10:44:20] <eburger> jdr: what is security relationship with Jon's model?
[10:44:28] <eburger> Jon P: none established a-priori
[10:44:39] <eburger> can thus force server to do CONSENT model
[10:44:50] <eburger> Also, justifies why to do this as a SIP thing, not other protocol
[10:44:58] --- allison has joined
[10:45:17] <eburger> jdr: however, this is exactly what is done for e-mail lists, e.g., SMTP for sending, HTTP for validation.
[10:45:32] <eburger> Jon: offers XCAP should be the mandatory to implement
[10:46:38] <eburger> Markus Isomaki: Besides Dean's case of lots of distributed exploders, there is the case of a local exploder. Thus should be OK to say, "I CONSENT to ALL users in a given domain"
[10:46:46] <eburger> Gonz: already possible
[10:47:11] <eburger> Hisham: Need to create event package, even if doing publish (BTW, don't like using publish)
[10:47:28] <eburger> "XCAP" won't be implemented is a poor excuse.
[10:48:15] <eburger> jdr: if an endpoint doesn't do HTTP, wouldn't need XCAP, as it can just use exploder URI (without even knowing it's an exploder URI)
[10:48:57] <eburger> jdr: Jon said that SIP has identity stuff in it; however, it is coming in HTTP and others, which have better protocol semantics for this problem
[10:49:58] <eburger> jdr: what about big lists? Don't want 1 person joining 2000 member list generating tons of consent requests; can't we do what we do for IETF lists where if you are "good" in the IETF, consent is implied
[10:50:30] <eburger> Cullen: Favors hybrid model: critical to remember that it is your AOR that gets consented
[10:50:53] <eburger> Cullen: wants to be able to revoke permission if I'm on a small device
[10:51:25] <eburger> Needs to be able to revoke using VERY lightweight device, as that may be all I have today.
[10:51:49] <eburger> NEW TOPIC: Transcoding Framework (transc-framework) - Gonzalo
[10:52:00] <tfroment> slides: http://www.softarmor.com/sipping/meets/ietf62/slides/pres-ietf62-sipping-camarillo-transcoding.ppt
[10:52:09] <eburger> Status slide
[10:52:16] <tfroment> draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-framework-01.txt
[10:53:57] <eburger> What's wrong with 3pcc? Lots of messages; some UA's can't support 3pcc
[10:54:16] <eburger> Proposals: Treat T as a conference; Address T as a proxy; Use new mechanism
[10:55:06] <eburger> Comparison slide
[10:55:40] --- bhoeneis has left: Disconnected
[10:57:23] <eburger> Jon P: important to note that route header means opening of man-in-the-middle attack
[10:59:12] <eburger> Eric: Conference model works; can also be used by UAS
[11:00:01] <eburger> Sharon Laivand: Route model has problem of sending needing to know transcoding required.
[11:00:14] <eburger> Also brings in permission problems
[11:01:14] <eburger> Medhavi: what about destination case?
[11:01:39] <eburger> Gonz: 3pcc works here; can also use creative redirection (proposed by Eric)
[11:02:39] <eburger> AGREEMENT: use Conference Model
[11:03:02] <eburger> NEW TOPIC: IPv6 Transition in SIP (draft-camarillo-sipping-v6-transition)
[11:03:06] <eburger> Gonzalo
[11:03:19] <eburger> Describes IPv6 transition (IESG mandate)
[11:03:40] <tfroment> slides: http://www.softarmor.com/sipping/meets/ietf62/slides/pres-ietf62-sipping-camarillo-v6-transition.ppt
[11:03:53] --- don_g has left
[11:03:56] <tfroment> draft: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-v6-transition-00.txt
[11:04:22] --- ogm has joined
[11:04:40] <eburger> Allison: v6ops group recommended we pursue this "in haste"
[11:05:01] <eburger> IESG has desire this gets done
[11:05:37] <eburger> Cullen: has been implementing v6 clients. There are multiple v6 vendors working at SiPiT
[11:06:57] <eburger> Proposal: adopt Gonz doc as WG item for IPv6 transition
[11:07:00] <eburger> Unanimous
[11:07:33] <eburger> NEW TOPICS: Functionality of Existing SBC's (Jani Hautak)
[11:07:48] <tfroment> slides: http://www.softarmor.com/sipping/meets/ietf62/slides/pres-ietf62-sipping-hautakorpi-sbc.ppt
[11:08:09] <eburger> The Drafts Slides
[11:08:10] <tfroment> drafts: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-sbc-funcs-00.txt http://www.ietf.org/internet-drafts/draft-bhatia-sipping-sbc-00.txt
[11:08:29] --- jean-francois has left
[11:09:07] <eburger> Scope slide
[11:10:14] <eburger> Spencer Dawkins: what work groups will we give info to?
[11:10:16] <eburger> Gonz: SIP
[11:10:19] <eburger> maybe SIPPING
[11:11:03] <eburger> Ben Campbell: If this expands work group work, then "no"
[11:13:00] <eburger> Gonz: Will just be input to work in group
[11:13:09] <eburger> NEW TOPIC: Back to Consent Framework
[11:13:47] --- jorma has joined
[11:14:17] <eburger> jdr: this affects basic SIP processing; thus XML may be out of scope as too much of a demand on small devices
[11:14:28] <eburger> thus what minimal stuff can we do?
[11:14:51] <eburger> offers one can do XCAP w/o full HTTP or XML stack
[11:15:45] <eburger> Jon: difference between XCAP and PUBLISH are slight; makes decision that much harder
[11:16:05] <eburger> If doing a uniform permissions framework, XCAP is way to go.
[11:16:16] --- jorma has left
[11:16:17] <eburger> However, can see being way to heavy for many uses
[11:16:28] --- bhoeneis has joined
[11:17:37] --- jorma has joined
[11:17:40] <eburger> Rohan: ease of implementation issue from jdr:
[11:17:52] <eburger> we have published specification TODAY for solution using SIP PUBLISH
[11:18:13] <eburger> Pick one! SIP PUBLISH as mandatory to implement makes sense because it works today
[11:19:30] <eburger> jdr: when want more flexibility in future, folks will want to incrementally expand PUBLISH, *not* move to totally different protocol (HTTP/XCAP)
[11:19:47] <eburger> Rohan: thinks that since some people are going to use XCAP, not an issue
[11:20:13] <eburger> Aki: carries really small device -- BTW, his really small device (tm) supports HTTP; doesn't support SIP
[11:20:27] <eburger> Paul: still worried about consent for registration
[11:20:48] <eburger> avalanche restart problem
[11:21:07] <eburger> Dean: we're talking about 3rd-party registration, not 1st-part registration
[11:21:14] <eburger> Gonz: take off-line
[11:21:35] --- allison has left: Logged out
[11:21:56] <eburger> Hish: we create an event pacakge, then we use PUBLISH to move it around. Here we are selecting PUBLISH *before* we have a package defined. Backwards.
[11:22:07] --- jorma has left
[11:22:14] --- jorma has joined
[11:22:23] <eburger> Argument against XCAP doesn't work as it is part of the configuration framework, which most everything will use.
[11:22:39] <eburger> Gonz: Don't forget P2P BBOF tonight after plenary (location TBD)
[11:22:53] <eburger> Dean: 3 proposals for consent: PUBLISH, XCAP, Hybrid
[11:23:21] <eburger> QUESTION to floor: which (PUBLISH or XCAP) would be minimum mandatory.
[11:23:24] <eburger> Cullen: why do now?
[11:23:42] <eburger> Dean: "Sticking thermometer into Turkey to see if done"
[11:23:54] <eburger> SHOCK: NO CONSENSUS
[11:24:13] --- ogm has left
[11:24:24] <eburger> Location for P2P may be Boardroom 2, but will be posted to SIPPING list
[11:24:30] --- bhoeneis has left: Disconnected
[11:24:30] --- eburger has left
[11:24:39] --- Minneapolis has left
[11:24:53] --- jorma has left
[11:25:16] --- tfroment has left
[11:25:28] --- jfb has left
[11:42:04] --- fluffy has left: Disconnected
[12:48:28] --- bert has left
[12:57:58] --- fluffy has joined
[12:58:16] --- fluffy has left: Disconnected
[14:34:19] --- wej has joined
[14:39:50] --- wej has left