Minutes taken by Steve Nadas from Ericsson (stephen.nadas@ericsson.com) Acee: OSPFv3 IPSec Automated key generation no longer on agenda. We need to pass requirements to MSEC WG. Joe Macker: IPSec usage issue is common to MANET protocols. Requirements to be coordinated. Acee: Yes - there are multiple protocols that will have/need similar IPSec automated key requirements. Presentation Acee: Document status - no new RFCs since 66 - see slides Authors to resolve - multi-topo - like to see interop - capabilitils - iesg commetns need impls/interop test - TE extensions for V3 tls from iana requested - wait on AD oks WG LC: rtr's local address in TE xtensions OSPF fot V3 - needs reviewers in rtg area (+ others for clarity/readability ) Multi-area adjacency - Respin and re-Last Call - Will become standards track rather than informational. OSPFv3 mib, traps added OSPFv3 multi-topo - needs rev and impl addr families - simpler but not fate share but adj overhead ospf - ll signalling --> to wg doc New non-wg drafts - See later in minutes OSPF manet drafts - No rough consensus as yet Presentation Michael Barnes : Crypto alg reqmts for OSPFv2 Some discussion on list already Crypto - only md5 to date, can be attacked, some want stronger algs perhaps should specify these How - 2328 can add other algs w/o too much problem This draft - new algorithms should be used and won't change proto fields, there is key-id field which can has an associated algorithm as a property. Adding crypto terms- SA's - will carry key/alg choice, fairly straight forward approach - should not cause backwards compatibility because no change to OSPF proto fields - it's mis-config if one peers has a different algorithm. Acee: IPSec for v3, once done, lacks replay and key dist issues on lan - w/v2 these problems are solved mainly (seq#>=, not monotonic incr). Vishwas present requirements in Paris in both OSPF and RPSEC WGs. Sandy Murphy, Sparta : what is manditory to implement? Michael - Separate doc will discuss what is req'd (ala ISIS approach) Presentation: Manav Bhatia - Crypto Requirements Document NULL, MS5, sha1, cryptographic - refs in this doc more algorithms keep coming eg des was once must, now is should ot What doc must, should, - running doc as algorithms come and go uses 2119 terms should+ = should may become must See slides and draft for specific requirements. Acee: "should not" wording is problematic for NULL and other existing requirements. Manav: NULL authentication is a "Should Not" in the case where the admin requirements OSPF security. Russ white: should may become a must vs. should+ (better to say what is meant) Manav: We have used these additional RFC2119 terms since the earlier cryptographic implementation requirement RFCs 4305, 4307 have used a similar language. Presentation Lou Berger: berger-ospf-rfc2370bis followon to ietf66 - opaque LSA across areas - problem w/validation - so instead rev'd 2370 Edited Igor's draft into 2370 2370 minor changes - draft format - non-standard MUST etc keywords - and upodated community needs to review to see if it's right - because the wording was once subjective and is now less so. See slides for other changes. Acee wanted MAY or Should added Acee: when we add new info to TE LSAs - scalability issues - give priority to base ospf LSA over the opaque LSAs. Lou: We should take to list whether MAY or SHOULD should be in the final text. Acee: Will validate on list that this is to become a WG document. Presentation Emmanuel Baccelli: presented in dallas - simulations - draft-baccelli-ospf-mpr-ext-02 MPR extension for MANETs, recent, simulations. See slides for presentation. Acee: Didn't make cutoff - draft is queue to be posted Acee: Interesting to compare w/other simulations mdr etc - Emmanuel: yes but much discussed Presentation Russ White: ospf/manet experimental MDR - Design team favored - No field test - Employs neighbor reduction Joe Macker: On list stated that MDR was field tested. OR - implemenmted , tested and getting deployed MPR - New entry - See slides for more info. Emmanuel Baccelli: MPR draft is 1 year old and OLSR is older. What are real requirements? Emmanuel: Use both random walks and boeing framwework using random wavepoint for simulations Russ: No good way to decide what should become draft standard - testing is limited - recommend experimental for multiple proposals and additional work. Tom Henderson: Disagree with characterization of MDR being primarily neighbor reduction benefits, we have shown that that MDR/OR achieve nearly similar flooding reduction but MDR goes further with neighbor reduction. Also, unfair to characterize MDR as unfit for life critical applications. Acee: Can use either approach (or all 3) with or without neighbor reduction. Russ: There may be MANETs where there is low density Tom: Agree but MDRs handles both low and high densities. Andrew McGregor: low dense vs medium density - there are cases where fixed networks acts like mobile because weather Stan Ratliff - This has been discussed - do we go forward with one or more drafts. Joe Macker - technical points - there has been good work done and have shown good results with adjacency reductino - these can be used in full link state mode - not clear mesh n/w's - there are cases where these techniques are useful Russ: Agrees with Joe. Joe: If things are close, try to pick one - and that was ourstragety initially - perhps reasdon to make decision Emmanuel: Agrees good work done - doesn't see experimental as a failure. Joe: Was dissapointed with failure to pick single solution - need to avoid over optimization Emmanuel: 3 proposals w/different mechanisms - don't see how to judge which is better - consensus simulations are necessary but not sufficient - need to go experimental in order to be able to judge Phillip Jacquet: Should over optimize or over invoated - MPR is based on MANET (OLSR) which has been around for some time - try to adapt these approaches - think 3 proposals are interesting Tom: defends simulations - are advantages to sim - used sharable and tests\ed code - MANET experiments are expensive and hard to reprodice and so there is cost for that approach - thinks all will work want to understand how to get 2 next step - what is looked for and how will we know in 2 years? Acee: happend in pim/cbt and vpn info distribution for VPLA - in 1 case CBTs died to due lack of implementations but for VPLS there are 2 ways to do it deployed. However, I don't see how we get to consensus given everyone who goes to the mike gives a different summary of where we are. Andrew - Some version will get deployed in an experimental network. We will have some results but these will be hard to reproduce. get some info - results are hard to reprodice - need to look for a long time on a real network - simulations are harder on network except that lots of packets are lost in the real network. Tom: This does not imply that we can't do experiments - however, these are expensive to do as thoroughly due to costs, and harder to reproduce. Thomas Clausen - No critcism for Design Team work - would be good to use test beds from MANET community - not overnight process but there are opportunities - reqmt's are soft so no need to force solution. We can try and get experimental results and would have more information to make decisions. Joe Macker - been doing experiments in MANET for some time - need to have good tools to collect results - network can break but not seen in experiment - traffic flow and mobility abtre both important (done 20-30 nodes) suppplement sims w/experiments some failure modes are only seen in sim Russ: simulations aren't enough. Thomas- Experiments - are necessary but not sufficennt - relatively low hanging fruit Phillipe: Risk for 500x500 node in middle cover 80% - not like real life - mayne solution for simulation. Stan - Don't throw simulatoins away - agree - Design Team has done good work - not enough info with just simulationss - need to proceed with multiple experimental draft. Acee: Asked Tom to discuss Design Team work in a few slides Stan - Like to see hum on 1 or multiple Acee: If one draft - how would we pick it? We've been unsuccessful heretofore to agree on criteria. Presentation: Tom Henderson: Summary of Design history - See slides. Emmanuel: First MPR drafts - 4 yrs old - 2002 time frame (response to timeline). See slides for timeline of design team. Bill Fenner: Echo disappointment on no consensus. We should not ignore simulations. It provides useful info - but more is needed - no opinion on how to proceed. Acee: one alternative: quit. 2nd: Continue trying to agree on single solution. 3rd: Multiple expeimrntal drafts - provide stable point for implementation and further experience. Bill: Are the drafts ready today? How long to refine and then publish? Don't keeping tweaking if since we want experience with various approaches ASAP. Acee: More like refine and publish (ro's) but one is stable - Criteria for publication is less stringent for experimental drafts. Emmanuel: MPRs is pretty close Acee: Show hands on what should be done: - Quit working on OSPF MANET: none - Continue to drive to consensus: none - Refine drafts and publish as experimental: 2/3's of people in room. To be validated on list. Acee: Refining and publishing is clearly the consensus of those here at the meeting. This is difficult for the OSPF WG since we are used to reaching consensus on a single solution and only arguing about encodings and corner cases that need to be documented. Emmanuel: What type milestone are we looking at? Acee: Should proceed ASAP to WG last call and publication as experimental. Bill: Encourage to do this pretty quickly - easy to keep iterating and it better to get a quick snapshot soon for more experience with the approaches. Joe Macker: One experiment MANET draft dragged for years - maybe here want converge - WG chair call to get control of iteration and enhancement creep... Acee: Experimental drafts (even WG) should be treated a bit differently than standards track WG documents. In this case, the authors should retain control over the content and move toward publication rather than making the content the collective property of the OSPF WG. Jabber Comment: Need to see new MPR draft and code before agreeing to publish. Acee: Since lots of good work has been done and we are going to publish more than one draft, we should publish those which meet the implementation and simulation criteria. ----- Presentation Acee: Docs on the Edge Ogier database exchange change draft --> Should move to WG doc. Please read it. Extracted from MDR work. There were no objections to making the draft a WG document. Update to hello (kou) - Vendors have implemented in many different ways. Unlikly to be standardised after the fact No recent discussion. holla-opsf-update-gr - helper criteria changed - explict GR signalling Is there a requirement for these ? Padma: read older draft & thought these were already known - most thought explicit signaling didn't offer much improvement over inconsistent LSA. Acee: If were a true requirement we could respin but author limit would be exceeded. Padm: First is internal operation and no requirement for second. Acee: Discussion in montreal - some thought it was useful - it would be good to discuss on the list again. Helper Criteria Change - No one in room views as required. Explicit Termination - Also no one in room views as required. mirtorabi OSPF tag - extra into for lnks/rts - Acee is author so thinks is needed - more discussion on list - haven't gotten those with requirements to present at IETF> ospf-v2 MTR mib - Since MTR was accepted as a WG requiremet than the MIB should be accepted. Will test on the list. OSPF WG WILL MEET IN PRAGUE JABBER LOG Taken by Thomas Clausen (thomas.clausen@polytechnique.fr). [20:50:05] --- thomas.heide.clausen@gmail.com has joined [20:53:38] (since these logs are kept, I'll try to do some notes, even though there's nobody here yet....) [20:54:20] Acee: agenda-bashing, some minor reorg of the agenda. [20:55:40] Joe Macker: IPSec usage issues - maybe there will be permission to turn seq. no on to do replay protection.... [20:55:50] Where would this be discusseD? [20:56:14] Acee: bis on RFC...ehh, missed the # [20:56:37] Joe: there might be more than one group wanting to do this. [20:57:02] Acee: WG status presentation. [20:57:20] Short time since last IETF, not a lot seems to have happened. Waiting on people to do things. [20:57:28] No new RFCs [20:58:09] ospf-mib in RFC editors queue [20:58:28] Two RFCs in requested publication state - still comments from IESG that need to be addressed. [20:58:38] Should be published in short order. [20:59:06] MT & cap: comments from IESG, worked on. Wanting to do interop, but not done yet. [20:59:37] Traffic engineering: WG last call, waiting for implementation -> std.track. [21:00:10] Seems straight-fwd based on experience with OSPFv2 traffic engineering. [21:00:20] Waiting for AD OK? [21:00:50] te-node-addr: authors will change ever so slightly, last call, then to the IESG. [21:01:16] OPSF for v6: last called, date past. Looking for reviewers from directorate - 100pg document ;( [21:01:49] Looking for clarifications, not changes or enhancements. [21:02:07] Multi Area Adjacency: in publication-requested [21:02:36] Want to pull back since there are implementations upcoming. Off-line requirements, another revision and then last-call again. [21:02:49] Should go std. track, regardless what IETF page says. [21:03:22] [21:03:35] --- Tsubasa has joined [21:04:40] Non-wg documents: discussed at the end of the session to evaluate if it is to go here or there. [21:04:51] Same for MANETs: no rough consensus, will be covered today as well. [21:05:33] Michael Barnes presents "Cryptographic algorithm implementation requirements for OSPF. [21:06:36] http://www3.ietf.org/proceedings/06nov/slides/ospf-6.ppt [21:06:42] --- Tsubasa has left [21:07:21] --- thomas.heide.clausen@gmail.com has left: Logged out [21:08:31] --- Tsubasa has joined [21:09:03] --- Tsubasa has left [21:16:07] --- thomas.heide.clausen@gmail.com has joined [21:16:15] Acee: one comment. Turned this down with the statement that we want to use IPSec. 03:10 Motivation fr doing this: lack of replay protection due to lack of e2e key dist on a lan or maccess network. 03:10 Build-in OSPFv2 auth, people have pretty much solved this problem. Seq# is not monotonically increasing with every packet, >= relation. Use clock-tick as seq#. 03:11 Thinks that we may as well go ahead - discuss a bit more and ask, before it becomes wg-doc, 03:11 Sandy Murphy: ask obvious question - will it be mandatory to implement? 03:12 Barnes: this document is just covering the more general "any algorithm" - there will be another doc. 03:14 Manav: different OSPF Auth Schemes (unscheduled presentation) 03:14 Refers to an I-D.... [21:18:18] Acee: I don't think that an impl can say "you should not implement this sec mechanism" [21:18:54] IPSec will probably die at some point. [21:19:19] Russ White: instead of SHOULD+/-, maybe rather say "this is currently a SHOULD, but may become a MUST in the future", since it's a bit of a codeword. [21:20:07] lou Berger: Update to the OSPF Opaque LSA option [21:20:26] http://www3.ietf.org/proceedings/06nov/slides/ospf-3.ppt [21:20:43] Update to previous discussion. [21:22:09] It's important for those in the community to review 2370bis, since there are things which before were not requirements which are. [21:22:36] Please do a careful review. [21:23:24] Needed input - discussions over a SHOULD and a MAY, see slide "Changes in Draft from 3270" [21:23:26] 2370 [21:24:47] Take it to the list. [21:27:21] Time to bring in any other changes now. [21:27:57] Acee: needs to be wg document, validate on the list.... [21:28:12] Acee: will rather ask "who thinks it should *not* be a wg document. [21:30:20] Emmanuel Baccelli: OSPF extension for MANET based on MPRs [21:30:39] draft-baccelli-ospf-mpr-ext-02.txt [21:31:02] (slides not on line, but since nobody is listening in here in real-time, I won't bother to type the content - check proceedings if consulting jabber logs post-meeting) [21:31:59] --- Tsubasa has joined [21:32:38] Emmanuel presenting MPRs as "subset of links in the network" [21:32:57] Properties: 2-hop coverage, shortest-path coverage. [21:33:06] Allows for flooding optimizations, adjacency reduction, topology reduction. [21:33:23] Validated both experimentally in manets, as well as theoretically [21:33:33] Recent developments: [21:33:41] following discussions in DT: [21:33:54] Modified to match structure of 2740 and 2328 [21:34:03] Newer heuristics...didn't get the rest of the slide. [21:34:35] --- josoinin@jabber.org/Meebo has joined [21:34:37] Simulation code based on GTnet on-line on some-url. Check slides when they appear. [21:34:37] Showing simulations, flooding efficiency etc. [21:34:46] Acee: figures are compared to normal OSPF, right? [21:34:50] EB: Yes. [21:34:55] Simulations show that main overhead is still LSA flooding. [21:35:36] Flooding efficiency, adjacency reduction, topology reduction benefits shown as compared to regular OSPF. [21:35:52] Topology reduction gives a substantial gain in the size of packets.... [21:36:03] 500x500 square, 50% gain. [21:36:22] #links advertised, 75% gain [21:36:41] Simulations confirmed with independant simulations outside of GTnet and common framework. [21:37:01] Consistent results between these simulations and the GTnet results. [21:37:23] Work on analytical model, trying to explain why LSA flooding overhead is larger than synchronization overhead. [21:37:26] Next steps: [21:38:15] Simulations are necessary, but there are no satisfying wireless model, the scenarii are too restrictive and all in all simulations are not sufficient to evaluate what goes on in read deployment scenarios. [21:38:25] Encourages experimental status to move forward with getting real-world experience. [21:38:40] Both for this and other approaches - seems to me to be the way to go. [21:38:43] (done) [21:38:58] Acee: This I-D didn't make the cut-off, so it is posted during this week. [21:39:38] Acee: one thing which would be interesting would be to see how this compares to others in the same scenarios. [21:40:02] Emmanuel: Might be interesting, discussed a lot on mailing-list. [21:40:20] Russ White: OSPF/MANET experimental [21:40:40] Based on what he has seen on list. [21:40:50] MDR: no known field-testing, primarily simulation [21:41:00] Primary reduction is neighbor reduction [21:41:09] http://www3.ietf.org/proceedings/06nov/slides/ospf-4.ppt [21:41:32] Joe: Mentioned on the list, there have been field-testing with MDRs [21:41:42] OR: implemented, tested and deployed [21:41:55] Relies on flooding changes for overhead reduction [21:42:57] EB: MPRs are older, and the MPR draft has been posted for more than a year. [21:43:15] Russ: Requirement issues - do not know which to choose. [21:43:24] We do not know if the simulations mirror the real world [21:43:48] Asks if MPR simulations use random waypoint or random walk? [21:43:51] EB: Both [21:44:11] Russ: We do not know if the simulation scenarios mirror this. Are simulations a good decission point? [21:44:29] We do not know which of these drafts are to become draft-standard. [21:44:41] We do not know if any vendors are requesting actual implementations. [21:45:01] Proposal: move forward to experimental, until we have more data to decide if we move fwd to std. track. [21:45:11] Tom Henderson: [21:45:19] Just wanted to say a few things which he disagrees with. [21:45:55] <<<>>> [21:49:27] Andrew: most common medium density, avg neighbors 4-8, not sensor, somewhat static - these proposals are a major win. [21:49:47] Stan: We've argued or discussed these issues (topology, ...) on the mailing-list [21:50:00] What it boils down to is: go we go forward with one or with more than one draft. [21:50:12] For now, all we know is based on simulations - one simulation scenario, [21:50:46] Supports going forward with multiple experimental drafts, since we *need* more experience. [21:50:49] Joe Macker: technical points. [21:51:10] It's important to not falsely argue [21:51:10] There's been good work done here. [21:51:10] We've showed topology improvements with many approaches. [21:51:24] Adjacency reduction was an additional step - validated what you hypothesised have happend. [21:51:32] Should be studied more, but it is a good first-step. [21:51:41] These proposals can be used in full ls mode, however. [21:52:34] Russ: that's why we should go experimental, [21:52:53] Joe: It's ok to keep optimizing, but we did sit down with the ADs, and this is something that we do not want to optimize. [21:52:57] If it's close, we're not going to pick one. [21:53:03] Feels that the approaches are very close. [21:53:19] Thinks that a decission should be made, since that was the approach they went in with. [21:53:36] Emmanuel Baccelli: agree that good work has been going on in Dt. [21:54:14] Disagree on one point: seems that people think that going experimental is a failure. To the contrary, this is the only reasonable way to go, [21:54:18] Joe: clarify - that's not my point, what I think that we should do is to avoid over-optimization, [21:54:55] Emmanuel: 3 different proposals. Different mechanisms for TR, Flooding Optimization, Adjacency reduction. Hard to judge which is better - there seems some consensus that simulations while necessary are not sufficient. [21:55:06] Supports going experimental. This should be for the three drafts. [21:55:16] Can't see how to judge between two or three [21:55:38] Philippe Jacquet: not a problem of over-optimization. [21:56:20] What we discover is not new, it's out of MANEt. Developed for several years. Could fill several slides with references to experiments with MPR-based solutions, and MPR-OSPF and ORCA are both MPR-based. [21:56:36] First way to work on the solution would be to start with what is out of MANET. MPR-OSPF is out of MANEt. [21:56:48] No use to over-innovate something new, which has no experimental background [21:57:13] tom Henderson [21:58:10] Thinks that we have basis for decission - experiments are notoriously expensive and hard to reproduce [21:58:21] think that all approaches can work [21:58:52] His problem with going experimental is how to then identify the next-step. How can we come back and make a decision later. Rather not have this happen [21:59:03] Acee: this has happened before, will rather not have it happen in his. [21:59:43] This doesn't seem to have enough, right now, marked requirement as if it has got to be there tomorrow. [21:59:50] Hard to say what's going to happen. [22:08:19] <<<< jabber scribe participating in discussion - refer to audiocast or minute-tager >>>> [22:08:24] s/tager/taker/ [22:10:01] Acee: Tom will go through a few slides of the design-team [22:10:30] Stan: wants to see a hum tonight from this group if we proceed on one or multiple [22:10:36] Think that we should proceed with three. [22:11:07] Acee: if we say one draft, then we need to find an agreed way of selecting. I do not believe that we have that. Was the question if now we want to go forward with multiple draft? [22:11:11] Stan: Yes [22:11:40] Tom's presentation: (slides not found) [22:11:50] Timeline: started by OLSR ported to OSPF protocol [22:12:03] Difference from that to what subsequently emerged was reliable or unreliable question [22:12:49] Discussion of when drafts emerged. [22:14:12] Emmanuel Baccell: wanted to reiterate that the first draft was the one working with MPRs. [22:14:57] Tom: continues, simulator, ... [22:17:32] --- josoinin@jabber.org/Meebo has left: Logged out [22:17:53] Acee: Bill Fenner (AD) do you want to say anything? [22:17:56] Bill Fenner: [22:18:07] Wants to echo the disappointment that no consensus solution has come. [22:18:48] Agree that simulation-only isn't sufficient, but simulations shouldn't be disregarded either. [22:19:04] Acee: two alternatives: [22:19:14] 1) Continue to try to come to consensus [22:19:26] Actually [22:19:26] 0) Give up ;) [22:19:30] 1) is to come to a single solution [22:19:53] 2) To, as russ suggests, publish multiple I-Ds as experimental get some stable specifications. [22:20:19] Bill Fenner: are there I-Ds ready to be published today? [22:20:39] Acee: Refined, probably. ORCA hasn't changed for a while. MDR should be simplified. [22:21:26] Emmanuel: OSPF-MPR needs a bit of refinement, but close to finished. [22:21:37] Hum on "quit"? -- none [22:21:53] Hum on "consensus"? -- none [22:22:24] Hum on "go experimental after refinement"? -- some [22:22:37] Oops, people were raising hands, not humming and I am in the front. [22:22:48] So I may not have been getting right on "quit" and "consensus". [22:23:56] OSPF has been fortunate/spoiled since, with the history and legacy solutions have thus far been obvious. [22:24:02] Emmanuel: what is the milestones and timeline? [22:24:14] Acee: when we feel we're ready to implement....we'll WG last-call them. [22:25:11] Bill: encourage that to be pretty quick. One of the thing we saw in old MANET regime was to tweak "one last thing", and go back and forth doing epsilon-improvements each time. Better to get something done quick, snapshot, as long as it is implementable and corresponds to what people are thinking. [22:25:18] Acee: will take this under advice. [22:25:29] Joe: One of our [manet] drafts that was dragging along took years. [22:25:54] Encourage to set up a milestone - this is a WG chair call. [22:26:04] Acee: all authors have been attentive to comments. [22:28:17] The 3 I-Ds should move forward to draft-ietf-ospf to go experimental. Don't think we can exclude one or the other, [22:29:14] But need, of course, to study carefully. [22:29:23] Acee: discussing the "lingering documents". [22:29:39] ogier-dbx - should get consensus to move to wg document. [22:29:49] Update to OSPF hello procedures. [22:30:11] --- Tsubasa has left [22:30:11] Many flavors. [22:30:34] Need to discuss where we want to go. [22:30:48] Acee doesn't feel that it is ready to go to wg doc yet. [22:31:09] Graceful Restart I-D. [22:33:11] Padma: do we see a requirement for this? Acee: we need to ask this question. [22:33:58] Acee: wondering if there's any more discussion. This is basically suggestions for graceful restart [22:34:24] Padma: most are internal optimizations [22:34:46] Acee: that's for termination. for explicit termination, there are ways you can do it which require changes to the protocol. [22:35:08] Padma: I am thinking that the first is internal optimization, and that we do not need the second (explicit signaling for GR helper termination) [22:35:49] Acee: give it one more tour on the mailing-list, to see if we think that either of these requirements are necessary. [22:36:37] Acee: anyone in here seeing the helper criteria as a requirement (none in the room) [22:37:04] Idemn for explicit signaling for gr helper termination? - looks like it echos Padma's feel for the requirements [22:37:18] Extension for advertising optional route / link attributes. [22:37:28] (disclaimer: Acee is co-author) [22:37:34] Thinks it is necessary. [22:38:19] Nobody seems to have read it in the room, need more discussion on it. [22:38:37] Tried to get some of the people who came up with the requirements to get involved, but not succesful. [22:38:48] MIB for MT.... [22:39:13] Anyone who doesn't think it should be wg doc (nobody), sufficient people have read it that Acee should be wg doc. [22:39:37] Conclusion: Ogier-dbx & MIB-MT should be asked to be wg documents, then? [22:40:04] Final question: how many plan to be in Prague? Seems enough to have a meeting. [22:40:26] Done. 3 minutes early. [22:41:14] **** [22:41:38] Scribe apologizes for having gotten names and details wrong. Was trying to participate in the discussion, which made it sometimes difficult.... [22:41:40] **** [22:42:02] --- thomas.heide.clausen@gmail.com has left: Logged out