IETF
websec@jabber.ietf.org
Wednesday, March 13, 2013< ^ >
Barry Leiba has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf85streaming.dnsalias.net/ietf/ietf852.m3u
Room Configuration
Room Occupants

GMT+0
[15:15:16] linlin.zhou joins the room
[19:06:17] ghcooper joins the room
[19:07:43] yaron.sheffer joins the room
[19:08:42] Andrew Biggs joins the room
[19:10:14] <yaron.sheffer> The agenda page lists a different link for audio: http://ietf86streaming.dnsalias.net/ietf/ietf864.m3u
[19:10:30] nico joins the room
[19:10:34] <nico> hi
[19:10:40] <yaron.sheffer> Hi Nico!
[19:10:52] <nico> I have the audio streaming
[19:10:58] <nico> but I'll join via webex in a sec
[19:11:25] <yaron.sheffer> WebEx is too much for us poor Linux souls
[19:12:00] <nico> oh
[19:12:01] <nico> no
[19:12:07] <nico> there's no webex for websec
[19:12:46] <nico> that kinda sucks
[19:12:55] PHB joins the room
[19:13:01] <nico> hi PHB
[19:13:09] <PHB> hi nico
[19:13:13] tlyu joins the room
[19:13:23] barryleiba joins the room
[19:13:27] hillbrad joins the room
[19:13:48] kazubu joins the room
[19:14:10] <yaron.sheffer> Barry, please correct the audio link at the subject line
[19:14:56] bkihara.l joins the room
[19:15:40] yngve_n_pettersen joins the room
[19:17:01] <hillbrad> hillbrad is taking notes
[19:17:07] <hillbrad> at mic: Jeff Hodges
[19:17:10] <barryleiba> /title WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf86streaming.dnsalias.net/ietf/ietf864.m3u
[19:17:10] <hillbrad> slide 3
[19:17:33] john.levine joins the room
[19:17:36] <hillbrad> original doc had a large number of references due to lack of survey papers
[19:17:45] Melinda joins the room
[19:18:01] <hillbrad> document can be simplified by referencing new survey papers by Weinberger and Li and Xue
[19:18:07] <hillbrad> slide 4
[19:18:28] <hillbrad> -01 in progress, needs review, hint hint
[19:18:30] <barryleiba> /topic WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf86streaming.dnsalias.net/ietf/ietf864.m3u
[19:18:38] <barryleiba> Damn.  Does someone remember how to do that?
[19:19:25] <hillbrad> Yoav Nir: how many have read this draft or that which preceede it?
[19:19:30] <hillbrad> *2-3 hands raised*
[19:19:42] <nico> how to do what?
[19:19:44] <nico> review?
[19:19:54] <hillbrad> JeffH at mic: in Atlanta, several people indicated they would review, would be helpful at this point
[19:20:16] <hillbrad> TOPIC: Key Pinning
[19:20:23] <hillbrad> Ryan Sleevi at mic
[19:20:23] <barryleiba> "That" == what I'm obviously trying to do with my messages above.  Can someone change the chat room title/topic?
[19:20:33] tlyu leaves the room
[19:20:38] tlyu joins the room
[19:20:41] synp joins the room
[19:20:43] <hillbrad> slide 2
[19:20:54] yaron.sheffer has set the subject to: http://ietf86streaming.dnsalias.net/ietf/ietf864.m3u
[19:20:55] nico has set the subject to: foo
[19:20:58] <nico> oops
[19:20:59] <nico> testing
[19:21:06] nico has set the subject to: http://ietf86streaming.dnsalias.net/ietf/ietf864.m3u
[19:23:21] <hillbrad> slide 3 _ issue 52
[19:24:13] <hillbrad> slide 4 _ problems issue 52
[19:24:45] <hillbrad> (slides are at http://www.ietf.org/proceedings/86/slides/slides-86-websec-2.pdf)
[19:25:23] =JeffH joins the room
[19:25:23] <hillbrad> slide 5 - discussion on issue 52
[19:25:47] sftcd joins the room
[19:26:00] <hillbrad> ekr at mic: seems generally satisfactory
[19:26:21] <hillbrad> should be able to specify a max-max?
[19:26:28] <hillbrad> ryan sleevi: seems sensible, but what should it be?
[19:26:31] =JeffH leaves the room
[19:26:40] <hillbrad> ... 30 days, or a scalable window based on observed patterns
[19:26:52] <hillbrad> ekr: nothing stops client from getting this info whenever it wants to
[19:27:09] <hillbrad> erk: also can forget whenever it chooses to for privacy reasons
[19:27:31] <hillbrad> ... at present this spec sould merely specify the max age which is valid and a maximum minimum for that value
[19:27:40] <hillbrad> ... 30 days, 3 million seconds sounds good to me
[19:27:54] <hillbrad> ... we might choose to provide guidance for the client to shrink that age based on observation period
[19:28:02] <hillbrad> .. client might choose to trust only for a day
[19:28:20] <hillbrad> Ryan Sleevi: each of these decisions impacts security considerations for value of this directive
[19:28:29] <hillbrad> ... what are guarantees if only lasts for a day?
[19:28:38] <hillbrad> ekr at mic
[19:28:59] <hillbrad> ekr: choice at client side is about avoiding being locked in when someone temporarily has a valid certificate
[19:29:06] <hillbrad> ... not misconfiguration
[19:29:18] <hillbrad> ryan sleevi: both attack and misconfiguration, but hopefully just attack
[19:29:22] <hillbrad> ekr: want to scope it to just attack
[19:29:44] <hillbrad> ... server shouled promise to have this available and not show any other keys for next 30 days
[19:29:48] <hillbrad> ... what client does, up to client
[19:29:51] <hillbrad> jeff hodges at mic
[19:30:05] <hillbrad> jeffh: in 6979 (HSTS) we didn't specify a max max
[19:30:08] tlyu leaves the room
[19:30:14] tlyu joins the room
[19:30:21] <hillbrad> ryan sleevi: reason is that certs themselves are constrained in time, greater operational constraints
[19:30:28] <hillbrad> ... for a key / ca vs. generalized use of https
[19:31:02] <hillbrad> ekr at mic:  if I accidentally set 4 quadrillion seconds, have permanently contaminated clients with a promise I can't keep
[19:31:20] <hillbrad> yoav: max max applies to client, not server
[19:31:37] <hillbrad> phb at mic: just occured to me as a CA, have to train my customer service people to help customers who screw up
[19:31:59] <hillbrad> ryan sleevi: goes back to operational concerns
[19:32:07] <hillbrad> next slide: Issue 53, private trust anchors
[19:32:19] <nico> the stream cuts out and i have to reload every so often :(
[19:33:08] =JeffH joins the room
[19:33:53] <hillbrad> ryan sleevi: can we have a way to let internal CAs to pin their own sites, but not break everyone who deliberately violates TLS end-to-end with a MITM CA
[19:34:06] <hillbrad> ekr at mic:  conflating 2 things
[19:34:27] <hillbrad> ... obvious requirement for people who are overriding the judgement of the public CA about the site to impose own CA for interception proxies
[19:34:38] <hillbrad> ... no sane person will turn on pinning if it overrides that decision
[19:34:47] =JeffH leaves the room
[19:35:14] <hillbrad> ... allow privately installed to override pins is different from saying private CAs are not allowed to pin
[19:35:57] <hillbrad> ... should say pins to private CAs should be respected as normal
[19:36:21] <hillbrad> ryan sleevi: strict attempts to do this, but public sites can screw up with strict
[19:36:38] <hillbrad> ... one possible implementation of strict is to only be strict with private CAs
[19:36:45] <hillbrad> ekr: suggest this is redundant
[19:37:01] <hillbrad> ... only exception is, if pinned, then observe private ca, overrid pinning
[19:37:11] <hillbrad> ryan sleevi: that is the same as saying any client policy can override pinning directive
[19:37:48] <hillbrad> next slide: Issue 53 discussion
[19:38:00] <hillbrad> yoav nir: worried orgs will fail PCI audit unless they set strict
[19:38:25] <hillbrad> paul hoffman at mic: what you (Ryan) said didn't match my understanding from mailing list
[19:38:48] <hillbrad> ... be very clear in new draft
[19:39:00] <hillbrad> next slide: issue 54, report-only
[19:40:31] <hillbrad> next slide: issue 54 possible problems
[19:40:39] <hillbrad> next slide: discussion
[19:40:46] <hillbrad> ekr: this is a fine implementation of what I was looking for
[19:40:55] <hillbrad> next slide: possible problems
[19:41:14] =JeffH joins the room
[19:41:28] <hillbrad> next slide: issue 55
[19:43:57] Andrew Biggs leaves the room
[19:43:57] <hillbrad> ekr at mic: does this mean all my preloads get rebooted every 6 weeks?
[19:44:16] <hillbrad> ekr: seems desirable to advise vendor to provide a timestamp with their last observation in preloads
[19:44:49] <hillbrad> next slide: 55, possible problems
[19:45:19] <hillbrad> ekr at mic: enough text on what a sane person would do is well-advised
[19:45:27] <hillbrad> next slide: issue 56
[19:45:40] <hillbrad> next slide: issue 56 possible problems
[19:45:44] tlyu leaves the room
[19:45:49] tlyu joins the room
[19:46:59] <hillbrad> jeff hodges at mic: was gnarly in HSTS, we decided superdomain wins
[19:47:15] <hillbrad> ... simple answer is do what HSTS does, but this is different use case, may need different policy
[19:47:45] <hillbrad> ryan sleevi: some have subdomains with narrower-scoped policies
[19:47:52] <hillbrad> ... individual pins that are subsets
[19:47:55] rscheff joins the room
[19:48:05] <hillbrad> ... which did you observe first?
[19:48:24] <hillbrad> ... does visiting a supersite with "includeSubDomains" after visiting a subdomain, does it overwrite?
[19:48:44] <hillbrad> ... or if policies are in conflict, connection might succeed or fail depending on observation order
[19:49:13] rscheff leaves the room
[19:49:14] <hillbrad> jeffh: agreed, more ops considerations required on this
[19:49:27] <hillbrad> yoav nir: pinned key could be end entity or issuer
[19:49:36] <hillbrad> ... never includeSubDomains for end entity key
[19:50:09] <hillbrad> ryan sleevi: can't even do this with a wildcard, due to single level of domain scoping
[19:50:21] <hillbrad> ... with exception of subject alternative names
[19:50:25] <hillbrad> ... more ops considerations
[19:50:32] <hillbrad> next slide: other issues?
[19:50:35] wilton@jabber.isoc.org joins the room
[19:51:32] <hillbrad> yoav nir: in 4.1 there is a requirement for backup pins
[19:52:00] <hillbrad> ... if ttl is month, backup key needs to be done a month in advance?
[19:52:44] <hillbrad> ryan sleevi: an example of a backup pin is to pin to a CA, and backup by pinning to several backup CAs, can get a cert issued if needed without having it always pre-issued
[19:52:59] <hillbrad> ... balance between security and operational risks
[19:53:10] <hillbrad> ekr at mic: should not support both HPKP and TACK
[19:53:16] <hillbrad> ... don't cross the streams
[19:53:26] <hillbrad> ... they can be in sync and redundant, or out of sync and its bad
[19:53:36] <hillbrad> ... DANE is a different question
[19:53:47] <hillbrad> ... TACK has no status in TLS WG at this point
[19:54:02] <hillbrad> ... guidance should be to use only one, not sure about order of operations
[19:54:27] <hillbrad> ryan sleevi: yes, introduces even more operational concerns for something already complex
[19:54:50] <hillbrad> yoav nir: DANE would be good to mention in association with self-signed certs in the draft
[19:55:01] <hillbrad> ... there are a few TODOs, would like to progress the draft
[19:55:24] PHB leaves the room
[19:55:28] <hillbrad> ryan sleevi: working on a new draft incorporating this feedback
[19:55:44] <hillbrad> back to chair slides: session management
[19:56:16] <nico> several HTTP auth proposals had session management as part of them
[19:56:41] <nico> (at least mine did, and still does as I still have to update it to use an external session mgmt protocol)
[19:56:43] <hillbrad> next slide on session management
[19:57:20] tlyu leaves the room
[19:57:25] tlyu joins the room
[19:57:50] Andrew Biggs joins the room
[19:57:54] <hillbrad> next slide: Do-Over
[19:58:38] <hillbrad> next slide: Do-Over (cont'd)
[19:58:45] <hillbrad> next slide: Session Management
[19:59:24] <hillbrad> change of slide deck to session continuation
[19:59:30] <hillbrad> http://www.ietf.org/proceedings/86/slides/slides-86-websec-3.pdf
[19:59:37] <hillbrad> Phillip Hallam-Baker at mic
[19:59:55] <nico> heh
[20:00:23] <hillbrad> next slide: Three Types of AuthN
[20:01:58] <hillbrad> next slide: TLS is not the answer
[20:02:40] <nico> another problem with TLS is that the more layers you have to cross to get at session / authentication information the harder it is to get to happen
[20:02:53] <nico> I don't really want to argue that TLS is no good
[20:03:07] <hillbrad> next slide: Problems
[20:03:32] <=JeffH> hey nico, yeah.
[20:03:37] <nico> cookies are used for purposes other than login session management
[20:03:42] <nico> i.e., user tracking
[20:03:49] <=JeffH> shopping cart
[20:04:01] <nico> right, pre-auth shopping cart
[20:04:02] <=JeffH> yeah, that's why the spec is called "state management"
[20:04:09] <hillbrad> next slide: Alternative
[20:04:41] <nico> (user eventually authenticates, in some cases, other times they pay without "authenticating" (though payment is authentication, in a way, at least when the payment is not anonymous))
[20:04:58] <hillbrad> next slide: Presentation Implications
[20:06:00] <hillbrad> next slide: Cookie Implications
[20:06:16] <=JeffH> nico:  let us know if you wish mic proxying
[20:06:31] <nico> how big is the time delay in the feed?
[20:06:41] <nico> I haven't measured it yet
[20:06:54] <hillbrad> next slide: Use Cases
[20:07:34] <=JeffH> brad is apparently checking
[20:07:40] tlyu leaves the room
[20:07:44] <nico> thx
[20:07:52] tlyu joins the room
[20:07:57] <hillbrad> (nico about 8 seconds)
[20:08:03] <hillbrad> (on the local net)
[20:08:07] <hillbrad> next slide: Requirements
[20:08:11] <nico> oh, wowo, that's a lot of lag :(
[20:08:20] <nico> thx for measuring
[20:08:29] <hillbrad> (yes, very confusing to listen to both!!)
[20:08:52] <synp> it's stil good enough to send "mic:" requests
[20:09:08] <nico> yeah
[20:09:10] <hillbrad> next slide: Content Binding
[20:09:39] <nico> if hillbrad's next slide messages are timely then the delay for me appears to be much less than 8 seconds
[20:10:01] <=JeffH> hey, not too bad, eh :)
[20:10:07] <wilton@jabber.isoc.org> nico: right, but for some kinds of payment, the place the user authenticates is not the same as the endpoint of their "shopping" session… (e.g. if redirected to PayPal, VbV etc…)
[20:10:15] <nico> =JeffH: what's not too bad?
[20:10:24] <hillbrad> next slide
[20:10:27] <hillbrad> Replay Attack
[20:10:34] <=JeffH> the delay -- i make lame joke attempt
[20:10:48] <hillbrad> (might be much more buffering in my local client)
[20:10:49] <nico> wilton: indeed, and that'd be "anonymous" (or pseudonymous) as far as the seller goes
[20:11:07] <wilton@jabber.isoc.org> =Jeffh: we'll laugh in 8 seconds ;^p
[20:11:26] <nico> there's no need for clock sync
[20:11:40] <nico> the server can tell the client it's time and the client can measure offset
[20:11:58] <nico> (you'd only need clocks, but not NTP)
[20:12:16] <nico> regarding replay protection: there's *many* solutions
[20:12:20] <hillbrad> phb: third option, not on slide: just use a counter
[20:12:23] <nico> e.g., windows of sequence numbers
[20:12:30] <nico> no, monotonic counter doesn't work
[20:12:41] <nico> because HTTP is not sequential
[20:12:41] <hillbrad> jeff hodges mic'ing nico's suggestion above
[20:12:52] <hillbrad> yoav nir: counter is hard with HTTP 2 multiplexing
[20:13:04] <nico> there's also bloom filters (insert MAC into filter)
[20:13:11] <nico> with sequence number windows it works
[20:13:29] <hillbrad> phb: avoiding replay attacks w/multiple streams implies larger state
[20:13:32] <nico> also, if you're using TLS then you don't need replay potection
[20:13:34] <hillbrad> next slide: TLS binding
[20:13:56] tlyu leaves the room
[20:14:01] tlyu joins the room
[20:14:21] <hillbrad> next slide: Realization
[20:15:00] <nico> lol @ "I did not do that"
[20:15:12] <=JeffH> :)
[20:15:26] <nico> I have been getting experience on existing HTTP clients
[20:15:28] <hillbrad> next slide: Next Steps
[20:15:38] <nico> adding HTTP auth options to many is HARD
[20:15:42] <nico> really, really HARD
[20:15:53] <hillbrad> jeff hodges at mic: yes, should do it, needs to be done, do it here
[20:16:07] <nico> yay @ =JeffH's comments
[20:16:22] <hillbrad> ... tying heavily to notion of user authn, perhaps is more about is a particular client / user agent responsible for all these disparate HTTP  messages
[20:16:22] <wilton@jabber.isoc.org> +1
[20:16:24] <nico> mic: =Jeffh: in my I-D there's support for unauthenticated sessions
[20:16:36] <nico> and for upgrade
[20:16:44] <hillbrad> ... is a special case of state management, not authentication per-se
[20:16:54] <hillbrad> ... some form of secure, client-initiated state mangement
[20:17:10] <hillbrad> phb: except you'll generate and somebody receiving them will put the request in a function and come up with a decision
[20:17:14] <hillbrad> ... that is an authN decision
[20:17:20] <wilton@jabber.isoc.org> There are different forms of AuthN going on at different levels (http session, TLS session, user authn level…)...
[20:17:56] <hillbrad> paul hoffman at mic: worth doing, at IETF, not sure if this WG is right, relative to HTTP Auth work
[20:17:57] <nico> =Jeffh: well, authenticating data is still authentication, and tying it to a possibly-authenticated session is still authentication, but it's not what you might think of as "initial authentication"
[20:18:09] <hillbrad> ... reuse of HTTP Auth headers is bike shedding
[20:18:16] <hillbrad> ... not clear if this is more http auth or more about web sec
[20:18:35] <hillbrad> yoav nir: as chair of http auth, has very narrow scope, websec WG has much broader scope
[20:18:46] <hillbrad> paul hoffman: not sure this room has as much experience as the other room
[20:19:05] <hillbrad> ... concerned that this may get forced into httpbis wg, they don't want it, but have expertise
[20:19:09] <nico> mic: @paul hoffman: re: HTTP auth, you're right that the two are related, and the thing is that a session management layer is much more generic, and could be used even with non-HTTP authentication methods (e.g., browserid, which is much more RESTful, like my RESTauth proposal)
[20:19:12] <hillbrad> ... already 3 proposed solutions, fairly similar
[20:20:02] tlyu leaves the room
[20:20:07] tlyu joins the room
[20:20:20] <hillbrad> phb: ADs wanted narrow scope for http auth
[20:20:28] <nico> mic: I also think that the way the HTTP auth WG is getting chartered it will not have the right audience either
[20:20:40] <hillbrad> jeff hodges at mic: agree w/nico, this is session continuation binding, not authN
[20:20:42] <nico> so the procedural issue really is relevant and informative
[20:21:00] <nico> maybe we need yet another WG! :^)
[20:21:07] <nico> (really, just kidding about yet another WG)
[20:21:08] <hillbrad> ... have not nailed down a precice definition for session or context
[20:21:27] <hillbrad> .. in terms of Paul's comments, don't touch existing WWW-Auth headers, use a new one
[20:21:53] <hillbrad> Robin Wilson at mic: are several kinds of state mgmt going on here, several intrepretations of authn already, have done some qualifications
[20:22:03] <nico> mic: I agree about new headers primarily because anything that doesn't interfere with existing HTTP stacks' internals is much more likely to be implementable (either in the stack or at the app layer)
[20:22:13] <hillbrad> ... that qualification needs to go further, within the definition you chose to address, still more layers
[20:22:31] <hillbrad> ... needs to be even more clear and expanded in more detail
[20:22:48] <nico> if you have Java apps using the JDK's crappy HTTP interfaces then you really, really, really don't want to have to go hack on the JDK...
[20:22:50] <wilton@jabber.isoc.org> *Wilton
[20:23:11] <hillbrad> yutaka oiwa at mic: needs to be sepeated session management and state management, e.g. context at Amazon might start as an anonymous user and later authenticate
[20:23:19] <=JeffH> yoav is enqued to channel nico
[20:23:25] <nico> thx
[20:23:26] <hillbrad> ... we should seperate these to allow more generality
[20:23:26] <synp> YukatA OIWA AT THE MIC
[20:23:40] <hillbrad> (Robin, thx)
[20:23:57] <=JeffH> synp == robin ?
[20:24:07] <synp> synp==yoav
[20:24:12] <hillbrad> (think wilton@jabber... is Robin)
[20:24:21] <nico> I used to want to argue for using the existing headers!
[20:24:28] <nico> then I found out that would make me sad!
[20:24:37] <hillbrad> back to chair slides: Session Mgmt summarization
[20:24:39] <=JeffH> oh
[20:24:40] <=JeffH> doh
[20:25:00] PHB joins the room
[20:25:27] <hillbrad> next slide: session mgmt, charter stuff
[20:25:49] danyork joins the room
[20:25:54] <=JeffH> ah -- I wudda said the above /before/ Phil's preso
[20:26:04] <nico> getting ahead of the chair, I hum in favor of adoption
[20:26:08] tlyu leaves the room
[20:26:13] tlyu joins the room
[20:26:38] <=JeffH> hillbrad @mic
[20:27:01] <nico> one of the nice things about this is that we could end up with enhanced UIs on the browsers regarding sessions
[20:27:25] <nico> mic: actually my problem statement I-D has requirements in it; we could separate them
[20:27:48] <nico> never mind the mic; it's been said independently
[20:28:31] <nico> mic: there's a requirement that it must be possible to implement a stateless variant by storing  state on the client
[20:28:36] <nico> you lose replay protection that way
[20:28:36] <hillbrad> sorry... I was looking just now at slides, not the doc
[20:28:45] <=JeffH> brad: have a prob stmt -- we don't have reqs stmt -- they are sorta diff -- there are things in http state mgmt today that are highly desirable & don
[20:28:50] <=JeffH> 't wanna loose 'em
[20:28:53] plh joins the room
[20:29:07] <hillbrad> next slide: Session Management, usual questions
[20:30:48] <nico> to give an example of how this is a real-world problem: I've seen deployments where only HTTP auth is used (generally RFC4559 HTTP/Negotiate with NTLM or Kerberos) and no cookies, so *every* request results in a 401, and then we authenticate just that one request
[20:30:59] <hillbrad> paul hoffman at mic: didn't say that I thought http auth was better place, could potentially be based on solution
[20:30:59] <nico> that's nuts
[20:31:13] <nico> (what's nuts is what I described, not anything that Paul said)
[20:31:22] <hillbrad> :)
[20:31:32] <nico> :)
[20:31:37] <hillbrad> ... need to decide on problem statement and who is going to use it
[20:31:45] <nico> Paul may well end up saying something nutty, but I doubt it
[20:31:49] <nico> ;)
[20:32:00] <hillbrad> .. may be that real requiements are not just a session, but what matters is to move authn across the session
[20:32:40] <nico> mic: @Paul: I'm *very* interested in not producing a session scheme that only works with HTTP auth and not, say, browserid
[20:32:52] <=JeffH> yoav notes that "authn" can happen at any place in various layers
[20:33:05] <nico> thanks Yoav
[20:33:40] <=JeffH> phb
@mic:  this prob is not all about authn, but is doing "authn" at some level (eg authn'g the msg and providing means to bind 'em)
[20:33:46] <wilton@jabber.isoc.org> hillbrad : correct… wilton at jabber dot isoc dot org is Robin Wilton
[20:33:50] <=JeffH> and its ok to do here
[20:34:03] <=JeffH> brad notes need right folks in room
[20:34:27] <wilton@jabber.isoc.org> (a perfect example of how tricky it can be to determine which end entity it is that we're trying to authenticate… QED ;^)
[20:34:57] <=JeffH> barry notes that in berline they are going to try to get the httpbis & http-auth (& websec) sessions on same or consecutive days
[20:35:35] <hillbrad> stephen farrell previously at mic: this may end up elsewhere depending on how requirements fall out, this is a good place to start on that at least
[20:35:44] tlyu leaves the room
[20:35:50] tlyu joins the room
[20:36:10] <hillbrad> handful of hands have read the doc
[20:36:17] <hillbrad> nods that it is a good place to start
[20:36:26] barryleiba leaves the room
[20:36:36] <hillbrad> open mic time
[20:36:56] <hillbrad> wrap
[20:36:56] sftcd leaves the room
[20:36:58] wilton@jabber.isoc.org leaves the room
[20:36:59] Andrew Biggs leaves the room
[20:37:12] <=JeffH> rsagent make minutes
[20:37:15] yngve_n_pettersen leaves the room
[20:37:24] <=JeffH> oh - wrong forum
[20:37:25] yaron.sheffer leaves the room
[20:37:29] PHB leaves the room
[20:37:32] Melinda leaves the room: Computer went to sleep
[20:37:42] <nico> so, that was possibly much too easy
[20:37:47] <nico> :)
[20:37:52] kazubu leaves the room
[20:38:08] <=JeffH> good pre-work
[20:38:40] PHB joins the room
[20:39:00] <nico> =JeffH: thanks.  And thanks to PHB for doing a great presentation
[20:39:39] <nico> there's nothing else going on in the room now, right? just ppl milling about?  I hear Yoav chatting with someone
[20:40:30] PHB leaves the room
[20:40:39] danyork leaves the room
[20:41:17] hillbrad leaves the room
[20:41:42] synp leaves the room: Computer went to sleep
[20:45:23] ghcooper leaves the room
[20:47:00] john.levine leaves the room
[20:49:11] cabo joins the room
[20:51:05] Andrew Biggs joins the room
[20:53:59] john.levine joins the room
[20:55:33] =JeffH leaves the room
[20:57:10] bkihara.l leaves the room
[20:57:31] bkihara.l joins the room
[20:57:54] bkihara.l leaves the room
[21:04:03] nico leaves the room
[21:05:25] Andrew Biggs leaves the room
[21:05:37] cabo leaves the room
[21:08:04] john.levine leaves the room
[21:11:22] plh leaves the room
[21:11:30] john.levine joins the room
[21:14:18] Andrew Biggs joins the room
[21:14:32] john.levine leaves the room
[21:15:54] john.levine joins the room
[21:22:45] PHB joins the room
[21:25:28] john.levine leaves the room
[21:27:36] john.levine joins the room
[21:27:50] Andrew Biggs leaves the room
[21:29:47] john.levine leaves the room
[21:33:36] john.levine joins the room
[21:35:29] john.levine leaves the room
[21:40:11] sftcd joins the room
[21:40:19] Andrew Biggs joins the room
[21:40:22] Andrew Biggs leaves the room
[21:40:26] sftcd leaves the room
[21:42:51] bkihara.l joins the room
[21:44:13] bkihara.l leaves the room
[21:49:18] tlyu leaves the room
[22:16:24] PHB leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!