[05:22:39] --- quinn has joined
[05:22:47] --- quinn has left
[10:07:32] --- Brian.Haley.hp has joined
[10:09:51] --- Brian.Haley.hp has left
[10:14:00] --- LOGGING STARTED
[11:12:27] --- quinn has joined
[11:23:33] --- saber has joined
[11:23:52] --- saber has left
[12:17:43] --- jjmbcom has joined
[12:59:30] --- LOGGING STARTED
[13:03:30] --- LOGGING STARTED
[13:42:33] --- quinn has joined
[13:58:02] --- jc_lee has joined
[14:03:11] --- momose has joined
[14:04:01] --- brabson has joined
[14:04:52] --- TJ has joined
[14:05:01] <TJ> Meeting starting - Basavaraj going over agenda
[14:05:11] <TJ> Gopal won't be able to make it; plane arrives at 4pm.
[14:05:31] <TJ> Status of WG documents - 2 new RFCs (4283 and 4285) - MN identifier option and Authentication protocol
[14:05:40] <TJ> Expedited through RFC editor's queue
[14:06:00] <TJ> MIB is not yet an RFC; still on RFC editor's queue
[14:06:24] --- Tsubasa has joined
[14:07:08] <TJ> Bootstrapping problem statement still has a couple of issues - MiTM attack, etc. Will revise by Gerardo
[14:07:23] <TJ> (Is anyone in here who is not at the meeting site?)
[14:07:51] --- geir_egeland has joined
[14:08:05] <TJ> New AD for MIP6 will be Jari Arkko. He is familiar with the protocol since he was the editor.
[14:08:52] <TJ> Question: Is there a reason why RFC 4285 is 128 bits instead of 160? I'll send an e-mail to the list for authors of RFC.
[14:09:32] <TJ> Any comments on MIP6 CN draft.. send to Francis.
[14:10:02] <TJ> New Design Team has been created for working on HA reliability issue.
[14:10:35] --- inet6num@jabber.org has joined
[14:10:35] <TJ> Has 5 members - Vijay, Ryuji, Behcet, Huideng..
[14:10:50] <TJ> By next IETF, we should receive problem statement and scope of reliability issue.
[14:10:57] <TJ> ---
[14:11:21] <TJ> MIPv6-v4 traversal update -- Hesham Soliman
[14:11:27] <TJ> (Joint NEMO-MIPv6 document)
[14:11:43] <TJ> draft-ietf-mip6-nemo-v4traversal-01
[14:12:00] <TJ> This is an update to the draft - won't go through the whole solution again.
[14:12:15] <TJ> The idea is to remove the independence between the address families in CoA and HoA.
[14:12:45] <TJ> Also supports NAT detection and traversal when you only have a private IPv4 CoA.
[14:13:08] <TJ> A number of issues addressed in this version of the draft (on slide)
[14:13:26] --- rjaksa has joined
[14:16:16] <TJ> 5 outstanding issues at the moment..
[14:16:32] <TJ> Issues 60, 70, 65, and dynamic detection of a NAT in the HA
[14:16:34] <TJ> 's domain
[14:17:43] <TJ> Issue 60 - keepalives. If anyone has an opinion / question on this, please speak up.
[14:18:20] <TJ> Suggestion is to add to next version of draft.
[14:18:31] --- shigeya has joined
[14:18:36] <TJ> Vijay - Problem with ping is that firewalls could just drop it. With a UDP message on some port, could be dropped
[14:18:42] <TJ> A: It's on the same port.
[14:18:55] <TJ> Vijay - Prefer the BU itself. I don't agree that it's expensive, and the message is protected.
[14:19:07] <TJ> A: Well it's heavyweight - you have to do encryption
[14:19:48] <TJ> John Loughney: There is a WG working on NAT traversal. Have you been checking what they're working on in terms of the lightweight mechanism? (BEHAVE working group).
[14:20:42] <TJ> Basavaraj: If this is standalone, it could be as you defined it. But SIP and BEHAVE WGs are working on similar solutions.
[14:20:51] <TJ> A: Well it's using the same port as the existing messages.
[14:21:20] <TJ> Avi L.: On point 2, the BU would be expensive for mobile devices. But on wireless links, it would be better if the AR or something could do it.
[14:21:31] <TJ> A: We're using UDP to traverse the NAT.
[14:22:05] <TJ> Vidya - I'd support this independent of BU, because lifetime of BU and NAT traversal are different.
[14:23:00] <TJ> Henrik L. - I'd like to question "expensive", because 1 packet every 110 seconds is 0.1% or less .. expensive, no. You have to take care to keep BU time separate from needed NAT keepalive time, but that is already described in the draft. So I see so need for alternative mechanism if we want to keep it simple and workable.
[14:23:46] <TJ> A: In general, keepalives are expensive for dormancy in cellular systems. Keepalives make it so you hardly ever become dormant. Depending on the kind of system, sending a packet as large as a binding update can affect the traffic channel, resulting in more work.
[14:24:06] <TJ> Third aspect is encryption, which I don't see as a big threat (sending this in the clear).
[14:24:26] <TJ> Henrik - I don't see a threat issue; I'm more concerned with not adding additional mechanisms if just sending a BU is acceptable.
[14:24:43] <TJ> Henrik - Different channel could be an issue, but I'd like to see a logical reasoning that shows this.
[14:25:19] <TJ> Alex P. - For some NATs I have used, it may be much less than 110 seconds. So the minimum in deployments...
[14:25:46] <TJ> Henrik - In the useage of MIPv4 clients I have used, 110s was never a problem. If you can show NATs that are shorter, we can adjust this.
[14:26:06] <TJ> Alex - And response to Vijay's comment -- Pings will probably be stopped by some NATs / firewalls
[14:26:21] --- nm has joined
[14:27:37] <TJ> (Discussion about firewall traversal and ports being used)
[14:28:51] <TJ> Vidya - Can we agree lifetime of BU is not the same as keepalive? So we want to keep the protocol simple - maybe we can send a BU with the bare minimum fields for the keepalive? It depends on the link you're going over as to whether it's expensive.
[14:29:09] <TJ> A: We can define a new BU option, but then it's a different message.
[14:29:35] <TJ> Henrik - We can rip out some parts of the BU when you just want a keepalive, but I'm not sure there are those fields you can remove.
[14:30:15] <TJ> Charlie P. - Expense of crypto protection for BU. Usually it's no more than a couple hundred ms. So a few thousand seconds over the course of a day, at the most, so it's considerable but not too much.
[14:31:05] <TJ> Charlie - So to standardize for NAT traversal, but someone decides they'd rather send a message to some web site, instead of using what's in this document, how could you say they're violating this published document?
[14:31:23] <TJ> Charlie - So you're proposing making a proposed std for something ...
[14:31:27] <TJ> A: Well ping is ICMP..
[14:31:38] <TJ> Charlie - So my question is why you need to standardize this?
[14:31:51] <TJ> A: Well, we are suggesting what to do for interoperability, just like anything in the IETF
[14:32:27] <TJ> Henrik - Of course, if you send traffic sufficiently often, you won't send a keepalive. Fine. But when a keepalive is needed, we show how to do it.
[14:33:35] <TJ> Alex P. - There may be no need for a keepalive if there an application communicating. But some NATs will dynamically change the outgoing port #, so even if you have ongoing streaming. This is discussed in the BEHAVE WG.
[14:33:59] <TJ> Next issue - dynamic detection of a NAT in the HA's domain. This was raised by Pascal, but we never discussed it in detail.
[14:36:53] <TJ> comments on this?
[14:37:53] <TJ> Kent L. - Actually, Pascal's not here. If you look at a superset scenario (more flexible scenario), it would be better. I haven't followed the details of this.
[14:38:06] <TJ> A: That's always true; just a question of the price. Do you know if many people are asking for this scenario?
[14:38:16] <TJ> Kent - I don't think we know who is specifically asking for it.
[14:39:10] <TJ> Vijay - I don't think we need this mechanism; if we do, it could be standardized separately.
[14:39:25] <TJ> Vidya - I agree we don't need a dynamic mechanism.
[14:39:34] <TJ> A: Let's bring this up on the list.
[14:40:11] <TJ> Henrik - I was originally against this (unnecessary complexity), but over the last year I realized that every time you put in something that needs more configuration, it complicates things. And it is very easy to make this work, so I'm now for this.
[14:40:28] <TJ> A: Problem is that I agree with both sides.
[14:40:48] <TJ> Next issue : Use of CoA option in BU. Vijay, can you explain?
[14:41:26] <TJ> Vijay - Second bullet is completely wrong. When you tunnel a BU, 3775 was mandating at least one format (HoA option). Tunnel mode is not addressed. It does not prohibit tunnel-mode BUs.
[14:42:09] <TJ> Michael R. from Microsoft wanted one single tunnel for HoTI and BU messages. So we decided not to prohibit tunnel-mode BUs.
[14:42:37] <TJ> Hesham - I disagree. This does violate what's in the text of the RFC.
[14:43:13] <TJ> This is an interpretation -- the RFC just says "this is how to send a BU", not how to send one in ESP
[14:43:48] <TJ> Francis - You need to specify how IPsec is used in transport mode with UDP encapsulation. There is nothing in this draft about that.
[14:45:20] <TJ> ---
[14:45:48] <TJ> Mobile IPv6 with IKEv2 and 2401bis - Update -- Vijay Devarapalli
[14:45:54] <TJ> This is a short update - just a few changes.
[14:46:31] <TJ> Jari A. had comments which we addressed. Haven't heard back from him yet.
[14:47:04] <TJ> (Going over changes in slides)
[14:48:21] --- sarolaht has joined
[14:49:28] <TJ> Jari A. - The original reason I was worried about K bit was that I wasn't happy with the IPsec details of the original RFC. So this is an opportunity to clean things up.
[14:50:24] <TJ> Vidya N - I think we should keep the K bit regardless, but we should clarify the behavior. What is the operation based on K bit value? I don't think the existing text is very clear.
[14:50:55] <TJ> Francis - I believe it's not clear because you need to know how to implement it to understand it. There is a draft telling one way to implement it, so I think this problem is solved.
[14:51:24] <TJ> Hesham - It's completely out of scope of this document -- if we decide to deprecate the K bit, it's a 3775 update issue.
[14:51:55] <TJ> Jari A- I think it's fine for this document to update the necessary parts in previous docs.
[14:52:11] <TJ> Hesham - If someone is implementing 3775, you would need to point them to this document as well.
[14:52:36] --- Brian.Haley.hp has joined
[14:53:12] <TJ> Vidya - If we go with deprecating K bit, wouldn't we be mandating MOBIKE?
[14:53:24] <TJ> A: There is no consensus to deprecate the K bit. So it will stay.
[14:54:14] <TJ> James K. - "Does not make sense to use MIPv6" bullet - Are you going to put something in the draft that specifically says if you use MIP6, you must not use MOBIKE? I think this is a problem, because if it's not explicitly said, people are going to use the two together and it won't work.
[14:55:30] <TJ> (Discussion of whether this should be done in the MIP6 WG...)
[14:56:21] <TJ> Gerardo - I think there is already a proposal in another standardization body to use them together.
[14:56:33] <TJ> A: In this case, the MIPv6 HA sits behind (something)... so it's not the same.
[14:57:03] <TJ> Jari - We've discussed about MOBIKE, but the key question is what does MIP6 want?
[14:57:23] <TJ> Vidya - We should look at the technical points behind keeping the K bit vs. using MOBIKE with MIP6.
[14:57:57] <TJ> Hesham - We can't escape the fact that this is all there because we removed the HoA option from the message in 3775 and 3776.
[14:58:45] <TJ> 3 modes of sending a BU.. won't go over this in detail .. (IPsec Selector Granularity slides)
[14:59:08] --- shigeya has left: Logged out
[14:59:24] --- Brian.Haley.hp has left
[15:00:10] <TJ> ---
[15:00:14] <TJ> Skipping next presentation.
[15:00:15] <TJ> ---
[15:00:26] <TJ> Goals for AAA-HA interface -- Gerardo Sandoval
[15:00:50] <TJ> Update for AAA goals interface document. Draft is fully reviewed based on solution from bootstrapping DT (both split and integrated).
[15:03:41] <TJ> vijay - Common goals ... we shouldn't require a solution in this WG to address ..
[15:03:59] <TJ> A: These are all the goals for the interface. We're not sure if we need a new diameter application
[15:04:33] --- Brian.Haley.hp has joined
[15:04:33] --- Brian.Haley.hp has left
[15:05:18] <TJ> Charlie - with goal 2.3, are you saying we need additional extensions and packet formats for QoS parameters and so on?
[15:05:36] <TJ> A: If an operator wants to put a restriction on the tunnel, such as packet filtering on the tunnel
[15:05:54] <TJ> Charlie: So are you asking if a document that fulfills these goals has to contain this extension specification?
[15:06:03] <TJ> A: If we agree on the goals, that this is important, then yes.
[15:06:14] <TJ> Charlie: Maybe multiple documents should be allowed to fulfill these goals.
[15:06:47] <TJ> [?} - For authorization, if we look at the AAA server, it is mainly authentication. But for authorization of servers or extension of the lifetime, is there a protocol that authorizes this?
[15:07:03] <TJ> A: These are the goals, not any particular solution. The authorization part is important.
[15:08:22] --- Brian.Haley.hp has joined
[15:08:26] <TJ> Hesham - 2.3 requirement seems a bit strange. I don't know if it should be there, but why would you want to do that? There is no way to force the packets to go to the HA all the time. Will this lead to strange behavior if you're talking to someone directly vs. through HA?
[15:08:36] --- nm has left: Replaced by new connection
[15:08:36] --- nm has joined
[15:08:41] <TJ> A: Idea behind this was to have packet filtering on MN traffic as you have in a NAS
[15:08:42] --- nm has left
[15:08:52] <TJ> We are not sure yet about that.
[15:09:25] <TJ> It's done in the NAS if you have a NAS. If you have an IETF network, you use the HA in the operator.
[15:09:43] <TJ> Hesham: But resources are an aspect of the access network. If the HA allows it, it's irrelevant.
[15:10:29] <TJ> Vidya - It is difficult to do this in MIP6. One of the use cases for this is logging in the HA, so that you do want to send traffic through there. But I don't see how it's possible in MIP6 unless you configure to never do optimization.
[15:11:19] <TJ> Vidya- For extension of authorization .. EAP AMSK behavior needs to be defined by EAP team outside of just MIPv6. So what they do there should be adopted by MIP6.
[15:11:35] <TJ> A: You're talking about AMSK for EAP over IKEv2 authentication
[15:12:27] <TJ> John L. - As chair for DIME WG, we're meeting on Tuesday evening. We are considering DIAMETER extensions to support MIP. We're counting on you guys to tell us what is required and will be deployed. If things are "may" it may be better to drop it.
[15:12:52] <TJ> Kent - For now, a "may" will suffice.
[15:13:28] <TJ> Avi D. - Do you really mean "enforce" or do you mean "assign" there? The AAA has to monitor whether something is happening, and if it's not happening, it needs to take action.
[15:13:34] <TJ> A: I think it's "assign". Thank you.
[15:14:04] <TJ> Main issue - scope of the draft.
[15:14:11] <TJ> I'd like to have a decision or at least some comments on this.
[15:14:45] --- sarolaht has left
[15:14:45] --- Brian.Haley.hp has left
[15:15:01] <TJ> Currently, lists the requirements for the HA-AAA interface. This is ok for the split scenario, but in the integrated scenario draft, this needs to be done using DIAMETER or RADIUS,.. so should we include this in the scope of the draft, or just keep it to the HA-AAA interface?
[15:15:54] --- Brian.Haley.hp has joined
[15:15:59] <TJ> Basavaraj - I think yes, it should include the integrated scenario. Intention was to have one document capturing requirements, which we can give to AAA wg..
[15:16:25] <TJ> Avi - I agree.
[15:16:52] <TJ> John L. - I agree as well. When do you expect that this will be done? If other WGs are working on solutions, it gets a little tricky.
[15:17:13] <TJ> A: It depends whether WG collaborates
[15:17:29] <TJ> Basavaraj - We believe it's good to broaden the scope. So I expect to have it stable by the next IETf.
[15:17:58] <TJ> [?] - I agree that one document is a good way to progress.
[15:18:02] --- Brian.Haley.hp has left: Replaced by new connection
[15:18:04] <TJ> ---
[15:18:06] --- Brian.Haley.hp has joined
[15:18:14] <TJ> MIPv6 bootstrapping in split scenario - Gerardo Sandoval
[15:18:24] <TJ> We already had a WG last call in December. this is a brief update.
[15:20:01] <TJ> (Going over issues on slides)
[15:23:02] --- Brian.Haley.hp has left
[15:23:34] <TJ> Vijay - What are you going to ask the IPsec IKE experts? We need to decide whether we're going to provide all the functionality in the RA when the MN is not at home, or not. Right now, it's just the mobile prefix discovery.
[15:23:38] --- Brian.Haley.hp has joined
[15:23:51] <TJ> A: A lot of people on the ML want to broaden this scope and provide multiple prefixes.
[15:24:19] <TJ> Vijay- Let's say IKEv2 folks say yes. MIP6 is not the right place to do it. If you want all the prefixes you would get at home, it's not MIP6 WG's problem.
[15:24:31] <TJ> (This is for the MIP6_HOME_PREFIX attribute issue)
[15:25:03] <TJ> Vijay - currently, you get one home prefix, then run MPD and get the rest of them.
[15:25:24] --- nm has joined
[15:25:31] <TJ> Basavaraj - Let's take this question to the list and get consensus on what question we want to ask IKEv2.
[15:26:32] <TJ> Francis - Currently the configuration stuff in IKEv2 was not designed to do this (?) thing.
[15:26:47] --- Brian.Haley.hp has left: Replaced by new connection
[15:26:59] <TJ> Alex P. - I'm not sure whether we still have a (?) for that. So you're suggesting not to use MPD because..?
[15:27:24] <TJ> A: I'm not saying that we won't use it. But people that think only one prefix is needed in this option say that we have MPD to get the rest of the prefixes.
[15:28:57] <TJ> ---
[15:29:28] <TJ> Testing interop, 8th TAHI IPv6 interop -- Sugimoto
[15:29:35] <TJ> Description, overview of testing.
[15:30:22] <TJ> Example message sequence..
[15:31:33] <TJ> Slides describe K-bit=0 and K-bit=1 message exchanges
[15:32:40] <TJ> Going over summary slide.
[15:33:02] <TJ> ---
[15:33:14] <TJ> Using MIPv6 for HomeLAN access -- Shinta Sugimoto
[15:34:41] --- thor101 has joined
[15:34:48] <TJ> Going over Background/Motivation slide
[15:34:59] <TJ> Extensions to BU message proposed (next slide)
[15:35:19] <TJ> Introduce extra bit (S-flag) to request link local HoA
[15:35:55] <TJ> MN can specify protocol and port # with LL scope multicast address to request forwarding from HA
[15:36:30] <TJ> Clarification on use of S-flag.
[15:37:53] <TJ> Security Considerations.. Strongly recommend using the IPsec tunnel
[15:37:57] <TJ> Summary.
[15:38:23] <TJ> Hesham - So you're limiting this to LL multicast traffic?
[15:38:29] <TJ> A: So far, yes.
[15:38:48] <TJ> The first motivation is to allow MIPv6 to operate in the home network.
[15:39:02] <TJ> Hesham - What's the application you have in mind? LL name resolution?
[15:39:30] <TJ> A: Applications based on uPnP framework, where you run SSDP to discover the services on the link. So the MN needs to initiate this discovery from a remote network.
[15:39:36] <TJ> Hesham - Can't you use a local address?
[15:40:41] <TJ> Dave Thaler - I agree with problem statement. A bunch of applications use link-scoped multicast addresses (such as SSDP), most of which are in Home LAN situations. The problem isn't limited to home lan, but this is the one most likely to affect home users. I'm giving a presentation on this in the Internet area meeting (next timeslot).
[15:41:13] <TJ> Alex P - When you say "Home LAN", you may have 2 or 3 subnets, but only one of which is your home link. So maybe you should use "House" instead of "home".
[15:42:13] <TJ> Dave - Houses that have multiple links are also problematic, even without mobility. so industry is trying to push things so a house only has one link.
[15:42:22] <TJ> ---
[15:42:38] <TJ> HA assignment with IKEv2 - Francis Dupont
[15:44:03] --- nm has left: Replaced by new connection
[15:44:03] --- nm has joined
[15:44:04] --- nm has left
[15:44:06] <TJ> Assignment is not the same as discovery. With discovery, the MN will pick a CoA, but with assignment, one is given from the the home network
[15:44:45] <TJ> (Security slid)
[15:44:50] <TJ> *slide
[15:45:10] <TJ> Main problem is DoS.
[15:46:11] <TJ> DoS for the MN has already been addressed by IKEv2.
[15:46:37] <TJ> What should we do with this draft?
[15:47:14] <TJ> Basavaraj: I don't really have an opinion whether we need another mechanism based on IKEv2 for HA assignment. Let's have more discussion on ML before we decide how to proceed. I'm not sure how many people have read the draft yet.
[15:47:51] <TJ> Basavaraj - Also, at Paris IETF, there was another proposal from Huidang as well, and we didn't take that work so let's have some more dialogue on how to go forward
[15:47:58] --- inet6num@jabber.org has left
[15:48:28] <TJ> Alex P - Comment on assignment and bootstrapping. It seems that in previous presentation, we can use IKEv2 to get home prefix to MN. We can also use MPD, which is fine. This could also be fine - use IKEv2, use DHAAD, ....
[15:49:06] <TJ> I believe it would be good to have a clear requirements document about HA assignment, etc
[15:49:20] <TJ> ---
[15:49:50] <TJ> MIPv6 bootstrapping with the Authentication OPption protocol -- Vijay Devarapalli
[15:50:39] <TJ> Current bootstrapping focuses only on IKEv2. But RFC 4285 is an alternative to IPsec, and doesn't have all the features of IKEv2. It's used by 3GPP2 and others.
[15:50:53] <TJ> So it would be good to develop bootstrapping for when IKEv2 isn't used.
[15:51:06] <TJ> (Going through slides)
[15:53:20] <TJ> Hesham - you're generating a key based on AAA authentication. I'm concerned there's a 'flavor-of-the-month' way of bootstrapping. I don't see a reason for having all these different ways.
[15:53:44] <TJ> A: I agree that we should have as few solutions as possible. But bootstrapping design team was focused only on IKEv2.
[15:54:06] <TJ> Hesham - so if there's a DIAMETER/AAA interface, why do you need anything between HA and MN?
[15:54:11] --- william.gilliam@2entwine.net has joined
[15:54:30] <TJ> A: A nonce provides freshness, and AAAhome delivers key via HA
[15:54:53] <TJ> So you generate a new key based on nonce each time it expires.
[15:55:04] <TJ> First BU goes to AAAhome, but subsequent BUs go to HA directly.
[15:55:51] <TJ> Basavaraj - Subsequent to bootstrapping design team, we have this auth protocol, so do we need a solution based on this?
[15:56:09] <TJ> Hesham - what happened between chartering and that? We are getting feature creep without a reason.
[15:56:57] <TJ> So going back to "Why" slide to discuss why it is needed
[15:57:44] <TJ> Gerardo - About SA setup, if you look at discussion on HOKE (?) BOF, most of what you specify here is not needed.
[15:57:48] <TJ> A: We don't use EAP here.
[15:58:21] <TJ> Basavaraj - We need to have further discussion on the justification for additional bootstrapping to be recommended by MIP6 WG.
[15:58:51] --- brabson has left
[15:58:52] <TJ> Gerardo - I'm not fully aware what's the status in 3GPP2 bootstrapping, but I think they've already defined their own solution, and this might apply to WiMax forum.
[15:59:13] <TJ> A: The fact that 3GPP2 and WiMax have defined 2 separate solutions. I haven't explicitly gone and asked them yet.
[15:59:55] <TJ> ---
[16:00:09] <TJ> Next steps - Basavaraj P.
[16:02:31] <TJ> Discussing splitting main RFC into many documents. Do we want to take on this work right now?
[16:03:00] <TJ> Jari A. - For clarification, proposal was more of a question, whether we want to issue a -bis draft, and if we do that, to split into multiple pieces.
[16:03:31] <TJ> We also need someone to take over document editor roles
[16:03:40] <TJ> Hesham - is router discovery part of this?
[16:04:07] <TJ> Jari - There are also a couple of mistakes which we can fix, and possibly structure the doc differently. Question is do we want to do that now, later, or when?
[16:04:23] <TJ> Hesham - Personally not knowing what those mistakes are, it would be good to leave it for another year to get more mature.
[16:05:14] <TJ> Basvaraj - My personal opinion is that when we start -bis work, we give impression that something is broken in base protocol. But taking this on might send the wrong message to implementors.
[16:06:06] <TJ> Jari - We can say that we are maintaining and not doing any redesign, or we can say we're reopening everything, which would send the wrong message.
[16:06:18] <TJ> Vijay - We whould revisit this 6 months from now, after bootstrapping
[16:06:46] <TJ> James K - I think it's not a good idea to reopen this, and although I originally supported it, I don't think we should break it apart into smaller documents either.
[16:06:53] <TJ> ---
[16:07:04] <TJ> Kunthal is going over 2 presentations..
[16:07:12] <TJ> (I have to leave... can someone else take notes for these??)
[16:07:30] --- TJ has left
[16:10:08] --- geir_egeland has left
[16:13:41] --- momose has left
[16:16:51] --- jc_lee has left
[16:23:08] --- rjaksa has left: Replaced by new connection
[16:25:30] --- thor101 has left
[16:27:58] --- Tsubasa has left: Replaced by new connection
[16:33:49] --- william.gilliam@2entwine.net has left
[16:35:50] --- quinn has left
[17:13:55] --- miya has joined
[17:14:14] --- miya has left
[17:18:08] --- miyahiro has joined
[17:19:56] --- miyahiro has left