[08:19:57] --- bubo has joined
[08:20:14] --- bubo has left
[08:45:21] --- iljitsch has joined
[08:48:46] --- lebb has joined
[08:49:24] --- jdq has joined
[08:52:04] --- Fred has joined
[08:52:35] --- WCerveny has joined
[08:53:51] --- dudi has joined
[08:55:16] --- FDupont has joined
[08:56:20] <iljitsch> iljitsch will be jabber scribe, kurtis will keep notes
[08:57:13] <iljitsch> if possible, it would be good if someone else could relay questions to the mic from jabber participants because I can't do that and type at the same time. :-)
[08:57:29] --- Yoshifumi Atarashi has joined
[08:58:21] --- gr8k@jabber.org has joined
[08:59:55] --- jft has joined
[09:00:42] <iljitsch> fred (cochair): nine o'clock and all is well
[09:00:51] --- dthaler has joined
[09:00:58] <iljitsch> see http://www3.ietf.org/proceedings/06jul/agenda/v6ops.txt for the agenda
[09:01:24] <iljitsch> see https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 for links to some of the slides
[09:01:54] --- aalain@trstech.net has joined
[09:02:30] <iljitsch> elwyn: want to talk about filtering recommendations, fred: will get it in
[09:02:56] --- narten has joined
[09:03:13] <iljitsch> skip nap draft until tony shows up
[09:03:37] <iljitsch> elwyn about transition/coexistence security considerations
[09:03:50] <iljitsch> AD (david) shows up, applause
[09:03:59] <iljitsch> elwyn:
[09:04:05] --- gordon.lennox has joined
[09:04:15] <dthaler> I'm not in the room, is this: http://www3.ietf.org/proceedings/06jul/slides/v6ops-8.ppt ?
[09:04:16] <iljitsch> document through wg and ietf last call
[09:04:37] <iljitsch> sorry, can't check for you, maybe someone else can?
[09:05:03] <iljitsch> iesg had a lot of comments, many philosophical and editorial in nature, many disclaimers are going in
[09:05:41] --- rdroms@jabber.org has joined
[09:05:42] <iljitsch> suggest doing things for security reasons that are within spec such as overlapping fragments, two ADs don't like this
[09:06:10] <iljitsch> solution: disclaimers
[09:07:31] <iljitsch> unusual padding patters are legal but may be malicious, draft suggests dropping
[09:07:41] <iljitsch> some issues with 3 vs 7 bytes of padding
[09:07:56] <iljitsch> need extra text for tiny fragments
[09:08:22] <iljitsch> [...]
[09:08:47] <iljitsch> suggest a sensible value for minimum size for non-final fragments = 50% of minimum mtu, but this is controversial
[09:09:13] --- narten has left
[09:10:10] <iljitsch> sensible implementation won't generate a non-final packet that is smaller than the minimum MTU
[09:10:16] --- narten has joined
[09:10:23] --- jpc has joined
[09:10:24] <iljitsch> bernard: what about overlapping fragments?
[09:10:41] <iljitsch> elwyn: should not be there, those should be dropped
[09:10:53] <iljitsch> iesg agrees this is stupid, evil and dangerous
[09:11:22] <iljitsch> lenghty discussion on handling of unknown extension headers/options
[09:11:35] <iljitsch> general view: administrators will probably want to drop these
[09:11:50] <iljitsch> but what's useful changes over time
[09:12:03] --- narten has left
[09:12:17] <iljitsch> so firewall should be configurable with what is unknown
[09:13:10] --- narten has joined
[09:13:25] --- kodonog has joined
[09:16:44] <iljitsch> i started discussion that if you drop unknown new extensions will be as good as impossible with this recommendation
[09:16:52] <iljitsch> fred: what's your solution?
[09:16:58] <iljitsch> other comments...
[09:19:16] <iljitsch> hum on whether this needs new text
[09:19:33] <iljitsch> most hum "no" but fred wants "yes" hummers to submit text
[09:19:58] <iljitsch> elwyn: don't use link locals for applications that aren't specifically designed to use them
[09:20:11] <iljitsch> tone down this recommendation, morre explanation
[09:20:28] <iljitsch> some other things we need to look at
[09:20:55] --- sakuma.macx has joined
[09:21:17] <iljitsch> other items discussed but probably no changes
[09:21:54] <iljitsch> amongst others some non-IPv6-specific stuff, don't feeel this is problematic
[09:22:07] <iljitsch> next: new last call or back to IESG?
[09:22:13] <iljitsch> fred: how much to do?
[09:22:26] <iljitsch> elwyn: little more than editorial, significant text
[09:22:32] <iljitsch> fred: so new wg last call
[09:22:51] <iljitsch> elwyn on draft on filtering icmpv6
[09:23:18] <iljitsch> minimal comments from wg and secdir, mostly editorial
[09:23:48] <iljitsch> talk about firewalls that are bridges rather than routers
[09:25:12] <iljitsch> is new text, private comments when drafts can be submitted again
[09:25:18] <iljitsch> fred: one week wg last call
[09:27:08] <iljitsch> david is up about bb-deployment-scenarios
[09:27:23] <iljitsch> unusal for ad to do document update
[09:27:31] --- kodonog has left
[09:27:38] --- sakuma.macx has left
[09:28:20] <iljitsch> explanation of current procedure, too complex to type...
[09:28:21] <dthaler> I don't see a presentation by this name on the site, is it there?
[09:28:34] <iljitsch> david claims he uploaded it but no
[09:28:36] --- bubo has joined
[09:29:17] <iljitsch> he is talking about different documents and what's happening with them but the document names are too long to be able to type them in fast enough...
[09:30:00] <Fred> Query to natpt authors: do you have any heartburn with the IESG taking the proposed action of moving natpt to historic?
[09:30:08] <iljitsch> icmp filtering will get ietf last call
[09:30:20] <iljitsch> most drafts have DISCUSSes
[09:30:31] <iljitsch> and need revisions
[09:31:09] <iljitsch> fred: clear path forward for all/most documents
[09:31:20] <iljitsch> pekka: do we need to talk about ...
[09:31:36] <iljitsch> natpt i think
[09:31:53] <iljitsch> iesg is thinking about moving it to historic
[09:32:09] <iljitsch> elwyn: we set out on this path
[09:32:27] <iljitsch> (speaking as document author)
[09:32:50] <iljitsch> [trying to find tony hain who is not tony li]
[09:33:09] <iljitsch> tony: there are products out, don't want their stuff be historic
[09:33:25] <iljitsch> fred: speaking as one of those vendors: huh? we also have rip
[09:33:37] <iljitsch> tony: that was the argument, perception proplem
[09:33:39] --- nm has joined
[09:34:00] <iljitsch> fred: the point was: not on standards track, right? ad: don't put on standards track
[09:34:02] <iljitsch> tony is up
[09:34:11] <iljitsch> slides are online
[09:34:20] --- onakayu has joined
[09:34:24] <iljitsch> (at leeast fred is supposed to have them)
[09:34:39] <dthaler> http://www3.ietf.org/proceedings/06jul/slides/v6ops-0.ppt
[09:34:43] <iljitsch> network architecture protection draft
[09:35:06] <iljitsch> grammar, clarity,
[09:35:15] <iljitsch> (see slides)
[09:36:12] <iljitsch> talking about IESG comments
[09:36:12] --- dudi has left: Lost connection
[09:36:12] --- rdroms@jabber.org has left: Lost connection
[09:36:12] --- jft has left: Lost connection
[09:36:12] --- lebb has left: Lost connection
[09:36:12] --- nm has left: Lost connection
[09:36:12] --- aalain@trstech.net has left: Lost connection
[09:36:12] --- jdq has left: Lost connection
[09:36:12] --- onakayu has left: Lost connection
[09:36:12] --- dthaler has left: Lost connection
[09:36:12] --- gr8k@jabber.org has left: Lost connection
[09:36:12] --- Yoshifumi Atarashi has left: Lost connection
[09:36:12] --- FDupont has left: Lost connection
[09:37:16] --- bruno.stevant@gmail.com has joined
[09:37:42] <iljitsch> fair number of wording changes, need new last call?
[09:38:02] <iljitsch> anonymous: unclear question
[09:38:22] <iljitsch> sorry people I don't understand the discussion so can't type it in for you...
[09:38:39] <iljitsch> anomynous: new wg last call
[09:38:59] <iljitsch> margaret: concerns, questions, (still don't know about what)
[09:39:48] <iljitsch> tony: about this version? haven't seen them
[09:40:19] <iljitsch> margaret: I'll forwad it
[09:41:33] <iljitsch> brian speaking as coauthor: read the comments, no reason to go to a different document
[09:42:06] <iljitsch> (move part of this to a different document)
[09:42:26] <iljitsch> tim: emphasize that this is informational
[09:43:14] <iljitsch> implication of using privacy addresses (although in wide use) not well understood, also for ula and prefix delegation
[09:44:03] <iljitsch> fred: when someone reads the document they don't check for maturity level so there should be some text about how fully baked this is
[09:44:09] --- FDupont has joined
[09:44:14] --- dudi has joined
[09:44:32] <iljitsch> fred: authors, talk to margaret, then post updated draft and then one week wg last call see where it goes from there
[09:44:33] --- jft has joined
[09:44:50] <iljitsch> tim: one other comment: in this document nat and firewall traversal, those aren't the same thing
[09:45:09] <iljitsch> tony: if you have recommendations...
[09:45:13] <iljitsch> tim: no...
[09:45:55] --- Yoshifumi Atarashi has joined
[09:46:14] <iljitsch> pekka on using ipsec for secure ipv6/ipv4 tunnels
[09:46:34] <iljitsch> short update, status is wg last call in august, one minor update since
[09:46:45] <iljitsch> since dallas one review from francis
[09:46:54] <iljitsch> one review from ipsec expert
[09:47:49] <iljitsch> please see slides
[09:48:13] <iljitsch> problem with tunnel mode,
[09:48:27] <iljitsch> solution could be to remove tunnel mode, thoughts?
[09:48:29] --- Onak has joined
[09:48:39] <iljitsch> fred: so all new implementations should remove tunnel mode?
[09:49:06] <iljitsch> pekka: no, but this is the only interoperable way to do it that we can think of
[09:49:21] <iljitsch> tunnel mode in other applications, can't make it work here
[09:49:41] <iljitsch> fred: tunnel mode is heavily used in military circles stuff that only works in tunnel mode
[09:50:18] --- dthaler has joined
[09:50:32] <iljitsch> pekka: and can't use mobike to change tunnel endpoints in case of mobility
[09:51:14] <iljitsch> francis: (I think he's saying:) more and more things over transport mode
[09:51:45] <iljitsch> pekka: so you support this solution
[09:51:56] <iljitsch> francis: yes, may be drastic, but...
[09:52:51] <iljitsch> fred: let's take this offline
[09:52:59] <iljitsch> would appreciate other comments
[09:53:39] <iljitsch> myung-ki shin about 802-16 draft
[09:53:59] <iljitsch> goal to provide scenarios for broadband wireless
[09:54:06] <iljitsch> for ipv6
[09:54:15] --- kodonog has joined
[09:54:30] <iljitsch> ieee 802.16 (wimax) is layer 1 and 2 so can add ip of your choice
[09:55:00] <iljitsch> commercial wibro service just started (IPv)
[09:55:12] <iljitsch> new 16ng wg in internet area
[09:56:08] <iljitsch> changes after talking with experts
[09:56:32] <iljitsch> amongst other changes since first version (see slides)
[09:56:38] --- jpc has left
[10:00:06] <iljitsch> we need more review and comments
[10:00:26] <iljitsch> then update and after than we expect wg last call
[10:00:41] --- nm has joined
[10:00:45] <iljitsch> fred asks for and gets three reviewers
[10:02:03] <iljitsch> marc about routing guidelines draft
[10:02:21] <iljitsch> routing in enterprise/provider networks
[10:02:46] <iljitsch> to replace 6bone routing guidelines rfc (something 77 IIRC)
[10:03:00] <iljitsch> 6bone is now gone, guidelines don't apply today
[10:03:18] <iljitsch> did some changes based on comments (see slides)
[10:04:20] <iljitsch> first version talked about not accepting prefixes longer than /48 in global routing table, comments, removed, then new comments...
[10:04:32] <iljitsch> (from registry people)
[10:05:00] <iljitsch> some choices: /48 is initial proposal, /64 is certainly safe, or don't mention any number at all
[10:05:11] <iljitsch> don't see consensus yet
[10:05:35] <iljitsch> we had a meeting with some of the commenters, not sure if we had consensus but there will be new documents
[10:05:58] <iljitsch> not sure how to proceed
[10:06:18] --- juampe has joined
[10:06:27] <iljitsch> todo: resolve prefix length issue, add multicast, rpsl code, minor fixes
[10:07:01] <iljitsch> wait for rpsl to stabilize
[10:07:34] <iljitsch> bernard: don't mention any prefix length to filter on, registry thing, not ietf thing
[10:07:48] <iljitsch> thomas: respectfully disagree completely, would be cop-out
[10:07:54] <iljitsch> (don't talk so fast thomas...)
[10:08:17] <iljitsch> what I heard was feeling deaggregating is not allowed but some want this
[10:08:34] <iljitsch> want document to say that this is a legitimate thing to do
[10:09:15] <iljitsch> *ogs and registries aren't places for document, need a home for such a document
[10:09:28] <iljitsch> marc volunteers to talk to them
[10:09:44] <iljitsch> fred: about this lunch time discussion yesterday with pekka, kurt and others
[10:10:00] --- Onak has left: Logged out
[10:10:20] --- kodonog has left
[10:11:08] <iljitsch> geoff's data shows that filtering on a specific length won't magically remove flapping and stuff from routing table
[10:11:17] <iljitsch> but it will keep the size of the routing table in check
[10:11:38] <iljitsch> there is someone from arin (marla), we'll hammer out a document
[10:11:45] <iljitsch> marla is asking us for advice
[10:12:16] --- ltn22@jabber.org has joined
[10:12:23] <iljitsch> knowing that people will do slightly different things for business reasons
[10:12:29] --- momose has joined
[10:12:39] <iljitsch> pekka: can deaggregate but not necessarily the best thing to do
[10:12:53] <iljitsch> kurtis: i think it's not appropriate for ietf to publish a number
[10:13:20] <iljitsch> but i hear thomas saying that he wants to see how multihoming can be done
[10:13:38] <iljitsch> there is a multi6 document that explains PA multihoming
[10:13:54] <iljitsch> alain: ietf is not <...> police
[10:14:17] <iljitsch> so document "thou shalt not deaggreate" is not appropriate, so tradeoff document is better
[10:14:24] <iljitsch> fred: this is the document that we're talking about
[10:14:54] <iljitsch> thomas: document to explain nuances, need to address perception that /32 is minimum prefix length
[10:15:11] <iljitsch> part of this is perhaps mythology, but originates at ietf needs to be undone
[10:15:52] <iljitsch> fred: would be nice if we could restrict routing table by filtering on RIR allocation boundaries but business reasons to do otherwise
[10:16:01] <iljitsch> thomas is happy to contribute
[10:16:15] <iljitsch> thomas: it's really pretty nuanced
[10:16:29] <iljitsch> can deaggreage in small region
[10:16:41] <iljitsch> fred: that's what marla's/my document will address
[10:16:53] <iljitsch> alain: reference to different document
[10:17:28] <iljitsch> marla: can you clarify about /48s, are they all announced, or only multihomed ones?
[10:17:41] <iljitsch> take it offline
[10:18:26] <iljitsch> thomas: there is 4177bis (I think) which is intended to become rfc, talks about /56 being ok for end-users, come out with comments
[10:18:30] <iljitsch> joe abley:
[10:19:58] <iljitsch> some rirs give out PI /48s for critical infra, those are somett
[10:20:17] <iljitsch> iljistsch: rirs should update their documents, there are still places that say filter on /32 is ok
[10:20:26] <iljitsch> thomas: (missed this one)
[10:20:44] --- Onak has joined
[10:20:48] <iljitsch> jordi: when we get PI those will come out of a specific super-block
[10:20:58] <iljitsch> not sure if this will be a global block or one for each rir
[10:21:32] <iljitsch> and apnic has /32 for their ownn infrastructure and announce a /33 which sometimes works and sometimes not, so guidance is needed
[10:22:08] <iljitsch> joe: not disagreeing, but not talking about PI but existing criticial infra policies
[10:22:19] <iljitsch> fred: take this offline
[10:23:20] <iljitsch> fred: marc are you done? proceed with document, people from meeting yesterday and others who are interested (pretty much a design team) will look at this one issue
[10:24:12] <narten> Document I mentioned is: draft-narten-ipv6-3177bis-48boundary-02.txt
[10:24:28] <iljitsch> ciprian popoviciu about addressing plan considerations
[10:25:06] --- juampe has left
[10:25:09] <iljitsch> two case studies: university of southampton, t-systems (service provider)
[10:25:27] <iljitsch> some changes done based on wg comments
[10:25:29] --- jpc has joined
[10:26:06] <iljitsch> (see slides)
[10:27:58] <dthaler> trying to find which slides on the site this is... anyone know?
[10:28:10] <iljitsch> not sure if they were uploaded
[10:28:14] <jpc> which ones ?
[10:28:19] <bubo> they are IMHO not uploaded
[10:28:28] <iljitsch> but this stuff is impossible to keep up with... sorry
[10:28:54] <iljitsch> going forward: want additional feedback, re3view of service provider case study
[10:29:08] <iljitsch> send them to document editor gunter van de velde
[10:29:28] <iljitsch> also want to know if we should include pi space discussion
[10:29:50] <iljitsch> non-scribe jabbber comment: PI is for multihoming, multihoming was out of scope, right...?
[10:30:04] <bubo> you're right
[10:30:04] <iljitsch> tim chown about scanning implementations draft
[10:30:36] <iljitsch> talk about what's new with IPv6 re scanning networks and provide recommendations on mitigation
[10:30:40] --- jdq has joined
[10:30:46] <iljitsch> new name after wg adoption
[10:31:08] <iljitsch> some changes after comments
[10:31:25] <iljitsch> comment: don't use "impossible" so now "harder", "more difficult"
[10:33:59] <iljitsch> even though scanning /64 is as good as impossible search space can be reduced in several ways, on-link nastiness
[10:34:31] <iljitsch> recommendations to get around this
[10:35:37] <iljitsch> comments requested, especially what you see in your networks
[10:37:23] <iljitsch> didn't catch name: seems to encourage head-in-the sand tactics
[10:37:44] <iljitsch> especially concerned with dns, should discourage reverse dns
[10:39:42] --- frodek has joined
[10:40:42] <iljitsch> iljitsch: point is that random scanning in ipv6 is useless, NOT so for targeted scanning
[10:41:10] <iljitsch> pekka: some address cnfiguration should go in dns, some not
[10:41:57] <iljitsch> alain: spending too much time to hide from scanning is counter-productive
[10:42:02] <iljitsch> tim: right
[10:42:27] <iljitsch> anonymous: there is a good paper about this
[10:42:36] <iljitsch> tim: I'll add a reference
[10:43:11] <iljitsch> inaudible: something about 7 bits / types of services / domains ???
[10:43:46] <iljitsch> fred: address these specific issues, other comments that come in, then wg last call
[10:44:19] <iljitsch> anders persson about issues with rfcs 4113 and 4022
[10:45:01] <iljitsch> deficiencies with these rfcs
[10:45:13] <iljitsch> talking about either mibs or mips, former seems more likely...
[10:45:58] --- Onak has left: Logged out
[10:46:07] <iljitsch> issue with tcp/udp connection/endpoint being tied to one system process, what if multiple processes have one open? (after fork() on unix)
[10:46:19] <iljitsch> or when process can't be determined
[10:46:50] <iljitsch> dave thaler (?): can answer some of this
[10:47:35] <iljitsch> lots of implementation specificness
[10:47:41] <iljitsch> if you fork you get a new instance
[10:47:52] <iljitsch> for udp, at least
[10:49:03] <iljitsch> the intention of the mib is that when you fork you end up with two instances
[10:50:17] <iljitsch> didn't hear: design team had big discussion on whether to add ipv6 or revise the mib, went with former
[10:50:37] <iljitsch> fred: so these are mib issues, not ipv6 issues, where should he go for this?
[10:50:50] <iljitsch> answer: ietf list, ADs...
[10:52:01] --- sakuma.macx has joined
[10:52:02] <iljitsch> fred: are there network issues in here?
[10:52:13] <iljitsch> anders: no
[10:52:22] <iljitsch> fred: find the right venue
[10:53:29] <iljitsch> pekka: not obvious if this is the right time for updating the mib, no implementations, but hopefully that will soon change
[10:53:46] <iljitsch> anonymous: interest on working this, talk to us
[10:55:59] <iljitsch> ruri hiromi about addr-select-ps
[10:56:08] <iljitsch> two related documents (see slides)
[10:56:21] <iljitsch> proposed to have policy info in dhcpv6
[10:56:29] <iljitsch> working code
[10:57:25] <iljitsch> about selecting addresses when there are multiple addresses from multiple prefixes, but multihoming out of scope
[10:57:58] <iljitsch> rfc 3484 starting point
[10:59:27] <iljitsch> source address selection issues: half closed network problem, site renumbering
[10:59:39] <iljitsch> dest addr: ipv4/ipv6 and...
[11:00:13] --- Onak has joined
[11:01:02] <iljitsch> half closed is about situation where one source address doesn't allow return reachability so the correct one should be chosen
[11:01:26] <iljitsch> site renumbering: long delays with autoconfiguration
[11:01:44] <iljitsch> rfc may solve this but policy will probably help
[11:02:09] <iljitsch> if site has native v4 and tunneled v6, v4 may be preferrred
[11:02:37] <iljitsch> ula / ipv4 dual stack environement
[11:03:15] <iljitsch> can't use the ulas to reach stuff on the internet, so shouldn't use that one in that case but want it for intra-site stuff
[11:03:29] <iljitsch> ula / global priorization
[11:03:51] <iljitsch> default rules don't provide guidelines
[11:03:58] <iljitsch> solutions:
[11:04:01] <iljitsch> manual configuration
[11:04:10] <iljitsch> but hard for average user
[11:04:30] <iljitsch> policy distribution in RA or DHCPv6
[11:04:35] <iljitsch> maybe something else?
[11:04:45] <iljitsch> experiments and implementation:
[11:05:03] <iljitsch> selected dhcpv6 because it allows centralized control
[11:05:24] <iljitsch> suspect better than in RA but that test isn't evaluated yet
[11:06:36] <iljitsch> is this worthwile v6ops work?
[11:07:15] <iljitsch> dave thaler: multihoming out of scope, host-wide vs per interface selection rules
[11:07:35] <iljitsch> stuff useful for source address selection, maybe not for destination
[11:07:44] <iljitsch> valuable to work on
[11:08:18] <iljitsch> need to deal with multihoming at some point
[11:08:31] <iljitsch> tim: still enough non-mh stuff but mh would be more useful
[11:11:24] <iljitsch> fred: seems to be interest, but need to liaze with shim6 and dhc
[11:11:31] <iljitsch> pekka: not with dhc at this point
[11:11:34] <iljitsch> tim: but move quick
[11:11:58] <iljitsch> rfc 3484 was a ipv6 wg thing, where does this happen now?
[11:12:06] <iljitsch> kurtis: 3484 in int area
[11:12:27] <iljitsch> pekka: yes they are meeting at 1 o'clock so you should probably be there
[11:13:13] <iljitsch> tim on ipv6 comus transition scenario desciption and analysis
[11:13:47] <iljitsch> how we deployed ipv6 on our campus, is pretty much a medium sized enterprise
[11:14:03] <iljitsch> valideate neterprise network scenarios text (rfc 4057)
[11:14:09] <iljitsch> document this
[11:14:45] <iljitsch> validate approach in sections 2, 3, 4 in rfc 4057
[11:14:54] <iljitsch> 1000+ hosts, 1500+ users
[11:15:09] <iljitsch> covered 95% of our needs
[11:15:17] <iljitsch> missed two things, including wlan access control
[11:15:47] <iljitsch> didn't use natpt, isatap, teredo
[11:16:04] <iljitsch> used vlans, ipv6 tunnel broker and 6tto4 if I'm not mistaken
[11:16:36] <iljitsch> comments?
[11:16:41] <iljitsch> is this useful?
[11:17:50] <iljitsch> address planning split off in own document, see earlier
[11:18:43] <iljitsch> elwyn: put it on the web as it continues to evolve?
[11:18:54] --- Onak has left
[11:19:30] <iljitsch> didn't hear name: should be informational rfc
[11:20:57] <iljitsch> tim will take out stuff that's subject to change and them see if the static part can be an rfc
[11:21:17] <iljitsch> benchmarking in ipv6
[11:21:59] <iljitsch> benchmarking working group??
[11:22:37] <iljitsch> need to think about hop-by-hop extension header needs special consideration
[11:23:08] <iljitsch> can have significant performance issues
[11:23:58] <iljitsch> we'd like feedback because this is important work
[11:24:13] --- momose has left
[11:24:22] <iljitsch> fred: no comments, if you're interested, go to benchmarking wg
[11:24:24] <iljitsch> we're done
[11:24:34] --- Yoshifumi Atarashi has left
[11:24:39] --- WCerveny has left
[11:24:42] --- gordon.lennox has left
[11:24:43] --- FDupont has left
[11:25:25] --- ltn22@jabber.org has left
[11:25:42] --- sakuma.macx has left
[11:26:19] --- bruno.stevant@gmail.com has left: Logged out
[11:26:24] --- Fred has left: Logged out
[11:26:42] --- dudi has left
[11:27:37] --- dthaler has left
[11:30:44] --- narten has left
[11:35:09] --- iljitsch has left
[11:39:02] --- jpc has left
[11:42:09] --- frodek has left
[11:42:09] --- jft has left
[11:42:11] --- nm has left
[11:51:16] --- jdq has left
[12:32:46] --- nm has joined
[13:04:12] --- nm has left
[15:37:11] --- danjared has joined
[15:38:00] --- danjared has left
[17:15:08] --- LOGGING STARTED