[10:15:53] Yoshi joins the room [10:16:02] Yoshi leaves the room [10:54:51] Yoshi joins the room [10:55:03] Yoshi leaves the room [10:58:49] Yoshi joins the room [10:58:54] Yoshi leaves the room [10:59:22] cjbernardos joins the room [10:59:32] tsavo_work@jabber.org/Meebo joins the room [11:00:48] jariarkko joins the room [11:00:58] Desire joins the room [11:01:15] Ulrich Herberg joins the room [11:01:28] vidya joins the room [11:02:13] sureshk joins the room [11:03:06] 22NDSTRE-934E1A joins the room [11:03:32] Yoshi joins the room [11:03:35] 22NDSTRE-934E1A leaves the room: Replaced by new connection [11:04:09] Marcelo presenting http://www3.ietf.org/proceedings/75/slides/netext2-0.ppt [11:04:45] slide 5 [11:05:25] 22NDSTRE-934E1A joins the room [11:06:18] julien to present http://www3.ietf.org/proceedings/75/slides/netext2-1.ppt [11:06:22] <22NDSTRE-934E1A> Testing (sorry for the intrusion...)! [11:06:26] the overview of the possible solutions [11:06:28] Ulrich Herberg leaves the room [11:06:31] no probs charlie [11:06:36] I am covering for you :-) [11:07:19] josoinin joins the room [11:07:53] slide 3 [11:08:01] slide 4 [11:08:36] slide 6 [11:08:44] JanMelen joins the room [11:10:39] slide 7 [11:11:01] slide 8 [11:11:35] slide 9 [11:11:55] slide 10 [11:12:55] carlos: He wants to know what changes are required on the MN to support uplink traffic [11:13:02] Ulrich Herberg joins the room [11:13:33] Julien mentions changing the route pointing to the outgoing interface [11:14:01] Carlos: mentions that this is already required for multi-interface nodes [11:14:16] anyrhine joins the room [11:14:30] <22NDSTRE-934E1A> George: nodes do not have a good way to decide which interface to use. [11:14:47] and that is why mif exists [11:14:57] <22NDSTRE-934E1A> Basavaraj: can restart things [11:15:05] Ulrich Herberg leaves the room [11:15:17] <22NDSTRE-934E1A> Basavaraj: and see which interface actually works. [11:15:25] Christian: need some co-ordination with network [11:15:49] this is why we require host changes [11:16:14] Sri: Do we need to distinguish use of 1 address vs multiple addresses (eg. HoA vs CoA) [11:16:18] Julien says no [11:16:36] Elena joins the room [11:16:50] <22NDSTRE-934E1A> Julien says this discussion is true for either PMIP or MIP [11:16:59] Marcelo clarifies that this presentation does not cover the difference between PMIP and MIP [11:18:03] Rajeev: There are other host changes not required for mobility and covered elsewhere [11:18:14] we need to focus here on the changes required for mobility [11:19:05] slide 11 [11:20:04] alide 12 [11:20:23] does audio work for others? I lost mine.. [11:20:28] It seems that the audio is gone. [11:20:43] back [11:20:46] audio works for me, but it has been very faint all the time [11:20:50] just when I asked.. [11:21:20] better? [11:21:29] I asked julien to speak up [11:21:51] I hear pretty well now [11:22:11] cool [11:22:36] slide 13 [11:22:38] OK, great. [11:23:02] alexmcmahon joins the room [11:23:23] Sri: Q on slide 12 [11:23:44] He wants to know where is the point of control in both cases [11:24:01] Julien mentions that it does not matter [11:24:11] what matters is that signaling is required [11:24:40] slide 14 [11:25:34] Sri dropped the mike [11:25:39] we are all safe here :-) [11:25:45] Sorry for the people on the audio. [11:25:56] <22NDSTRE-934E1A> The mike fell by itself -- Sri rescued it from the floor! [11:25:58] Questions? [11:26:24] You most probably have to see a doctor for ears... [11:26:51] Carlos: Why are complexity and deployment issues not covered, but only signaling? [11:27:05] Julien: Hard to quantify [11:27:45] JanMelen leaves the room [11:28:21] <22NDSTRE-934E1A> Julien: Complexity is a detail. If we do a foreign agent for IPv6, we don't need to know exactly where the mobile is. [11:28:53] <22NDSTRE-934E1A> Jonne: agree with Julien, complexity is in the eye of the beholder. Not appropriate when discussing requirements. [11:29:11] <22NDSTRE-934E1A> Julien: need these kinds of signaling in both cases. [11:29:29] <22NDSTRE-934E1A> Carlos: need security to connect with the MAG. [11:29:44] <22NDSTRE-934E1A> Julien: yes. [11:30:01] <22NDSTRE-934E1A> Carlos: need to authenticate, not like bootstrapping. [11:30:25] <22NDSTRE-934E1A> Marcelo: the point of this presentation was just to set the landscape. Then we will get into details. [11:30:59] <22NDSTRE-934E1A> Marcelo: It's just preliminary background stuff. Not intended to be exhaustive. [11:31:45] <22NDSTRE-934E1A> Telemaco Melia: Doesn't take into account, it enables multihoming, but may not be necessary with the building blocks you will have. [11:32:16] <22NDSTRE-934E1A> Suresh: BOF is run as a rechartering exercise for netext. Not trying to answer whether PMIP or MIPv6 is better. [11:32:38] <22NDSTRE-934E1A> Suresh: The question is just whether we can do what is needed with more signaling. [11:33:13] <22NDSTRE-934E1A> Sri: points out something is a requirement, disagreement. [11:33:22] <22NDSTRE-934E1A> Marcelo: we are just trying to find the requirements. [11:33:51] <22NDSTRE-934E1A> Sri: we already require access authentication. [11:34:57] <22NDSTRE-934E1A> Greg (IAB): if the work proceeds (asking for undestanding) the left side is more of a profiling exercise. The right side requires more work (sides of slide 14). [11:35:52] Ralph Droms joins the room [11:36:01] <22NDSTRE-934E1A> Carlos: we are distinguishing between signaling vs. mobility signaling. [11:36:12] <22NDSTRE-934E1A> Answer: just to find the requirements. [11:36:14] it will be covered in the requirements presentation [11:36:20] <22NDSTRE-934E1A> Rajeev starts his presentation. [11:36:32] http://www3.ietf.org/proceedings/75/slides/netext2-2.ppt [11:37:28] slide 2 [11:37:31] <22NDSTRE-934E1A> Discussion at last IETF, before that the Dublin bar BOF. [11:38:07] slide 3 [11:39:27] jon joins the room [11:39:38] slide 4 [11:40:49] jonne: clarifies that interface in this context means an IP interface and not a physical interface [11:41:11] George: Is it the same mobile? [11:41:16] Rajeev: Yes [11:42:05] Raj: Base 5213 allows this already with creation of a new mobility session [11:42:14] <22NDSTRE-934E1A> Basavaraj: Would like to have it be the same mobility session. [11:42:25] the new thing we need is to continue the session in the new access [11:42:51] Rajeev: MAG2 needs to disambiguate handovers vs fresh attach [11:42:56] slide 5 [11:43:47] George: clarifies that MN is not involved in PMIP mobility [11:44:02] and hence wants to know what the first bullet means [11:44:04] <22NDSTRE-934E1A> Rajeev: mobile sees the same IP address. [11:44:44] <22NDSTRE-934E1A> Rajeev: no signaling between MN and LMA. [11:46:07] George: mentions that the LMA does not manage anything [11:46:22] but merely reacts to MN interfaces attaching and detaching [11:47:05] slide 6 [11:47:35] Marcelo: This is the main reason for this meeting [11:47:42] look at the slide carefully [11:47:58] are these requirements valid? [11:48:35] George: Are you open to the case where there is no consensus on requirements and there is nothing further to do [11:48:45] Marcelo: nods reluctantly [11:49:10] I assume all discussions assume session continuity for both IPv6 and IPv4? [11:49:24] I would think so. [11:49:36] including private IPv4 addresses... [11:49:41] But that is a point that can be discussed. [11:50:11] <22NDSTRE-934E1A> So far, IPv4 has not been mentioned. [11:50:29] <22NDSTRE-934E1A> And IPv6 has been mentioned quite a few times. [11:50:41] Ralph: wants to know if all flows will be moved [11:50:46] or only partial moves [11:51:19] tsavo: All these cases are covered by DSMIPv6 (RFC5555) [11:51:25] Clarifying question to Rajeev: do you agree with Julien's assertion that in order to do what is required, we need new software in the hosts and signaling between the host and the MAG? I am asking because your formulations on slides 5 and 6 are not very explicit about this. [11:52:15] <22NDSTRE-934E1A> Suresh relays Jari's question. [11:52:23] Rajeev 4 more slides to go [11:53:03] host changes can be classified into different types [11:53:12] S736548CEF7F67 joins the room [11:53:32] * if a host has a virtual interface and if it is just configured to use it [11:53:38] * extensions at L2 [11:53:53] he does not consider these as host changes [11:54:05] CHENGANG joins the room [11:54:16] the only thing he considers as host change is L3 protocol changes [11:54:42] Marcelo: Rephrase as requirements [11:54:51] e.g. No L3 protocol changes [11:55:05] Rajeev points to slide 6 bullet 3 [11:55:46] he mentions that changes to RS/RA are perfectly fine [11:56:23] says who? an MN that cannot speak one protocol but can speak another for the same purpose sounds strange [11:56:34] <22NDSTRE-934E1A> Apparently everything is O.K. as long as the mobility is only "clarifying" some sort of access characteristic. [11:56:44] @vidya: I agree with you [11:57:16] <22NDSTRE-934E1A> Basavaraj: not trying to say how the MAG finds out that the mobile is reattaching. [11:57:31] add to that the need for securing RS/RA once there is actual sensitive information in it [11:57:50] you are back to contradicting bullet #2 [11:57:57] follow-up: on bullet 3: I can see what you have written, but my question is: are those indications REQUIRED in order to provide the functionality that you want to achieve? Lets work from what we NEED to do to what the solutions are (and not just try to avoid host changes at a particular layer). [11:58:08] <22NDSTRE-934E1A> Marcelo: this is a key requirement -- don't want to touch the mobile node (!) [11:58:38] <22NDSTRE-934E1A> Marcelo: need to have a clear answer!! [11:58:43] <22NDSTRE-934E1A> Marcelo: !! [11:59:24] I'd say that mandating or relying on L2 changes is outside the scope of IETF and hence cannot be a requirement we assume is satisfied [11:59:36] <22NDSTRE-934E1A> Rajeev: extensions to existing protocols are something we should consider. [12:00:08] there is an existing protocol. It is called MIP6 [12:00:17] <22NDSTRE-934E1A> Jonne: Rajeev is saying that avoiding host changes is NOT a requirement. [12:00:25] <22NDSTRE-934E1A> Rajeev: I am not thinking of a new protocol. [12:01:35] <22NDSTRE-934E1A> Ralph (AD hat on): trying to move the discussion. What _is_ a change to the mobile node? Need to write down some categories of changes. There are some gray scales to whether there are changes. [12:02:13] <22NDSTRE-934E1A> Ralph: it seems that we are not requiring that there be no changes to mobile node. But it depends on the kind of change. [12:02:42] <22NDSTRE-934E1A> Ralph: Once you have decided to change the mobile node, he is reminded of an off-color old joke. [12:03:09] <22NDSTRE-934E1A> Jonne: Rajeev is saying that the first bit is zero and we are going to look at the others. [12:03:40] <22NDSTRE-934E1A> Greg: Is there always a L2 trigger, or are other triggers allowable, using the same L3 interface. [12:03:58] <22NDSTRE-934E1A> Rajeev: I am talking about access-to-access movement. [12:04:15] <22NDSTRE-934E1A> Rajeev: IF1 --> IF2. [12:04:30] Elena leaves the room [12:04:31] <22NDSTRE-934E1A> Julien: Slide 6 is the only slide for requirements? [12:04:36] <22NDSTRE-934E1A> Rajeev: Yes. [12:04:54] <22NDSTRE-934E1A> Julien: What is the reason for "No security association provisioning"? [12:05:05] <22NDSTRE-934E1A> Rajeev: points to slide 4. [12:05:29] <22NDSTRE-934E1A> Jonne: Julien is not asking how PMIP works, he just wants to know why security is off limits. [12:05:58] <22NDSTRE-934E1A> Rajeev: We don't have to deal with security today, why should we need the additional burden for multiple access? [12:06:10] <22NDSTRE-934E1A> Julien: What if it comes for free? [12:06:44] <22NDSTRE-934E1A> Rajeev: But if we have access authentication today, we still don't have to have SA configuration and management. [12:06:44] I don't get something fundamental... the MN needs to provide information about the handoff, but without a security association? [12:07:04] <22NDSTRE-934E1A> Julien: this is narrowing too much the range of solutions available. [12:07:34] <22NDSTRE-934E1A> To Vidya: I agree this is a major flaw. [12:07:58] <22NDSTRE-934E1A> But if the provider has orthogonal access authentication, it seems to be pardonable. [12:08:34] <22NDSTRE-934E1A> Julien: what about a system that isn't deployed yet that does not have access authentication? [12:08:48] not really, since there is no requirement that access authentication be tied to the IP address... and we can't assume it is [12:08:50] <22NDSTRE-934E1A> Rajeev: Regardless of mobility protocol, you are likely to have access authentication. [12:09:01] but access authentication is for a different purpose [12:09:07] it has nothing to do with IP addresses [12:09:11] <22NDSTRE-934E1A> Jonne: Let's all calm down. [12:10:16] <22NDSTRE-934E1A> Rajeev: For the default scenarios we are considering, we do have access authentication. Can't see putting requirement in when MAG is managing millions of users. [12:10:46] <22NDSTRE-934E1A> Ralph: Isn't security association question orthogonal to the question of handover? [12:11:00] <22NDSTRE-934E1A> Rajeev: In previous solutions, there is no signaling. [12:11:16] <22NDSTRE-934E1A> Jonne: Want to understand the requirements for reattachment. [12:12:14] <22NDSTRE-934E1A> Suresh: We agree on access authentication. Why is it harder to do between MN and LMA than between MN and MAG. [12:12:29] <22NDSTRE-934E1A> Rajeev: Already mentioned that MAG is likely to be on the path. [12:12:46] <22NDSTRE-934E1A> George: Access authentication is done with AAA. [12:12:47] anyrhine leaves the room [12:13:09] <22NDSTRE-934E1A> George: LMA does not need to have preconfigured associations, because LMA can get this from the AAA. [12:13:19] <22NDSTRE-934E1A> George: This is one way of creating security associations. [12:13:43] <22NDSTRE-934E1A> George: Some people think you need to have L3 security. [12:14:16] <22NDSTRE-934E1A> Rajeev: if you go to some AAA server, sure you can go to LMA if you want to. [12:14:33] <22NDSTRE-934E1A> Rajeev: But if I don't have to do it, why should I? [12:14:47] <22NDSTRE-934E1A> Rajeev: Then I don't have to save any state on the LMA. [12:15:36] <22NDSTRE-934E1A> Julien: Don't want to enter discussion of complexity, but I disagree with what you way [to Rajeev]. You get the security association, then keep it forever. We aren't discussion key management. We are discussing mobility. [12:16:02] <22NDSTRE-934E1A> Julien: We will figure out the security after we understand the mobility requirements. [12:16:20] <22NDSTRE-934E1A> Julien: There are security tools available. [12:16:37] jon leaves the room [12:16:48] <22NDSTRE-934E1A> Rajeev: Let others also answer that question. Keeping the state requires more memory. [12:17:56] <22NDSTRE-934E1A> Kent: Is there a compromise here? Today, PMIP doesn't have additional changes for this. We should favor the case where PMIP doesn't require extra security. If that can't be achieved, then we leave open that we may need to add more security infrastructure, [12:18:17] I would suggest we move on from this point. I think the other requirements are valid, but the second one is more of a constraint or characteristic related issue. Once we get to comparing the different solutions, this is one (but just one) of the factors to consider. [12:18:37] Elena joins the room [12:18:51] anyrhine joins the room [12:18:56] <22NDSTRE-934E1A> Suresh: Proposing way forward: make the requirements are clearly written, and that would go into the charter. [12:19:14] <22NDSTRE-934E1A> Jonne: That's is what we are trying to do. [12:19:28] Yes. [12:19:31] <22NDSTRE-934E1A> Suresh: two steps: do people _understand_, and then do they agree. [12:20:07] I for one don't think that the other requirements are valid either, FWIW [12:20:07] <22NDSTRE-934E1A> Sri: Today we do not require extending security to LMA. Today, mobile doesn't even know LMA exists. [12:20:41] <22NDSTRE-934E1A> Subir: Suggest no signaling between MN and LMA. [12:21:05] <22NDSTRE-934E1A> Ralph: Relays Jari's request to move on from jabber. [12:21:20] the first requirement should read more along the lines of the MN being able to do multihoming and inter-access handovers; not necessarily the PMIP6 domain being able to do that [12:21:47] <22NDSTRE-934E1A> Marco: Talking about enabling use cases. We shouldn't assume MIP in the background. Julien [12:22:05] <22NDSTRE-934E1A> Marco: If it's easy to put security on the mobile, it's easy to put software on the mobile. [12:22:20] <22NDSTRE-934E1A> Marcelo: We can't discuss this any more. [12:22:41] <22NDSTRE-934E1A> George: Is this the complete list of requirements. [12:22:44] <22NDSTRE-934E1A> Jonne: it [12:22:55] <22NDSTRE-934E1A> Jonne: it's the complete list of _proposed_ requirements. [12:22:59] Elena leaves the room: Replaced by new connection [12:23:00] Elena joins the room [12:23:06] <22NDSTRE-934E1A> George: first bullet is not a requirement. [12:23:40] neither is the 2nd or 3rd one [12:24:02] <22NDSTRE-934E1A> Rajeev points to slide 4. [12:24:16] <22NDSTRE-934E1A> Jonne: both of you are right. [12:25:24] <22NDSTRE-934E1A> Marcelo: This is what we are trying to provide. The requirements don't give information. [12:25:44] <22NDSTRE-934E1A> George: Could you clarify the 4th bullet on slide 6. [12:26:34] <22NDSTRE-934E1A> Rajeev: so called "slow mobility" problem [??] [12:28:07] <22NDSTRE-934E1A> Suppose (e.g. for load balancing) LMA is seeing a lot of HTTP traffic. Suppose it wants to move some traffic from one interface to another. [12:28:28] <22NDSTRE-934E1A> Rajeev: right -- it amounts to rerouting, not handover. [12:28:52] <22NDSTRE-934E1A> [that comment was from Greg Lebovitz] [12:29:24] <22NDSTRE-934E1A> Christian: The first requirement is really the right kind of requirement. The problem with bullet 2/slide 6 is that it is too low-level. [12:29:54] <22NDSTRE-934E1A> Marcelo: but if the requirements are too high-level, it does not help us know where we are going. [12:30:36] <22NDSTRE-934E1A> Christian: but first we need to know whether the requirements are wanted by anyone. [12:31:04] <22NDSTRE-934E1A> Suresh: On bullet 3, it is extremely vague. Can we tunnel a binding update as an extension to RS? [12:31:20] <22NDSTRE-934E1A> Suresh: we need to clarify what we mean by mobility signaling. [12:31:59] <22NDSTRE-934E1A> Rajeev: context for bullet 3: MN is telling the MAG it has moved. [12:32:09] yeah, so, it is a binding update [12:32:14] just sent in a different protocol [12:32:26] <22NDSTRE-934E1A> Suresh: should say that the mobile node can't do any signaling that a fixed node would not do. [12:32:45] <22NDSTRE-934E1A> Rajeev: So the mobile can't tell it is moving? But that is the problem we are trying to solve! [12:33:12] <22NDSTRE-934E1A> Julien: We need to say what it means to have inter-access handover, but the mobile cannot manage its own mobility? [12:33:49] <22NDSTRE-934E1A> Rajeev: But mobile does still not know its LMA. [12:33:59] <22NDSTRE-934E1A> Julien: You are saying things now that are not written down. [12:34:07] <22NDSTRE-934E1A> Rajeev: I could use your help. [12:34:30] <22NDSTRE-934E1A> Rajeev: I am having a problem trying to articulate the point. [12:34:43] <22NDSTRE-934E1A> Julien: I agree with Suresh -- this is mobility signaling. [12:35:05] <22NDSTRE-934E1A> Rajeev: If a mobile runs DNA, is that mobility signaling? [12:35:35] <22NDSTRE-934E1A> Rajeev: Telling MAG that interface has changed is not the same as mobility signaling. [12:36:10] <22NDSTRE-934E1A> Ralph: Clarifying point: first bullet is a set of goals. But it has a piece missing -- should also say "flow mobility". [12:36:37] <22NDSTRE-934E1A> Ralph: That brings me to bullet 4 -- only with flow mobility, does the mobilehave to handover across interfaces. [12:37:00] Yoshi leaves the room [12:37:03] <22NDSTRE-934E1A> Ralph: this is now an optimization to tell the LMA how to move the flows. [12:37:27] YGHONG-X300 joins the room [12:37:36] <22NDSTRE-934E1A> Ralph: So LMA controls flow mobility. [12:38:10] <22NDSTRE-934E1A> Ralph: you want to have flow mobility, LMA controlling one way, MN controlling the other way. LMA makes an optimization decision, and needs to signal it down. [12:38:35] <22NDSTRE-934E1A> Ralph: Bullet #3, we are not going to come to consensus on how ot phrase it. [12:39:03] <22NDSTRE-934E1A> Marcelo: This is the mobility; we need to write it down. [12:39:30] HUI joins the room [12:39:30] <22NDSTRE-934E1A> Sri: Need to have mobile node to provide the indication. [12:39:54] <22NDSTRE-934E1A> Sri: is it policy? Exchanging policy with the network is not exactly mobility signaling. [12:41:02] <22NDSTRE-934E1A> Marcelo: You can call it what you want. We can say that the requirement is poorly phrased. [12:41:17] <22NDSTRE-934E1A> Marcelo: This is what you think. [12:41:29] <22NDSTRE-934E1A> Sri: no I should be able to say what I mean. [12:41:43] <22NDSTRE-934E1A> Jonne: The question is whether we capture what the group wants. [12:42:11] Overall observation: we have some work left on the requirements. I see two types of needs for enhancing them. First, they should be expressed in a solution agnostic manner. Secondly, they need to be accurate enough so that we know exactly what is needed. I have suggested text for item 3: the network and the MN must be able to signal the role of a new attachment (handover or new interface) so that an inter-technology handover can be achieved without change of IP address. But this probably needs document work after the meeting. [12:42:17] <22NDSTRE-934E1A> Suresh: bullet #3 is insufficient. My proposed text is that any signaling is nomt mobility signaling. [12:42:43] <22NDSTRE-934E1A> Sri: THat' [12:42:49] <22NDSTRE-934E1A> Sri: that's the wrong definition. [12:43:08] <22NDSTRE-934E1A> George: The requirements are too few and too vague. [12:43:52] <22NDSTRE-934E1A> George: What is missing is the general form of the solution space -- whether to use existing protocol, or rely on layer two, or ... [12:44:09] <22NDSTRE-934E1A> Rajeev: I can go through the other slides. [12:44:37] <22NDSTRE-934E1A> Jonne: relays Jari comment from jabber -- basically that more work is needed and requirements stated in solution-agnostic manner. [12:44:38] HeikkiMahkonen joins the room [12:45:33] <22NDSTRE-934E1A> Rajeev: How long are we going to iterate on this? I think we ought to find out whether people want to solve the problem or not? It's been nearly a year now. [12:46:01] <22NDSTRE-934E1A> Marcelo: the clarity is that we don't know if these are requrements. [12:46:30] <22NDSTRE-934E1A> George: I am trying to say what additional is needed. In the solution space, what are you going to require? [12:47:03] <22NDSTRE-934E1A> Rajeev: I can show right now! Let's move on! I am not ready for another year. [12:47:14] <22NDSTRE-934E1A> Basavaraj: We are not going to change the mobility model. [12:47:28] <22NDSTRE-934E1A> Basavaraj: The mobile is not going to be managing its mobility. [12:48:32] <22NDSTRE-934E1A> Basavaraj: The mobile needs to provide a hint. In addition: need to hide the physical interface from the mobile [??] [12:48:40] Elena leaves the room [12:49:09] <22NDSTRE-934E1A> Rajeev: Whatever you guys want to do, I can do it. Let's move forward. [12:50:17] <22NDSTRE-934E1A> Ralph: Based on the what's been seen here, there is interest here. Before there is a working group, we need a set of requirements that everyone can agree on. Need to be able to discuss coherently. [12:50:34] <22NDSTRE-934E1A> Ralph: There's work to be done, it would be great to have a working group. [12:50:42] With DSMIP6 host gets inter-access mobility to networks not having MAGs (no access network dependency). With possible PMIP extensions mobility is always contained to PMIP domain only. In both cases there are changes to hosts that need to be both implemented and verified... [12:50:52] <22NDSTRE-934E1A> Greg: Do they have to write the requirements first, or the problem statement? [12:51:25] <22NDSTRE-934E1A> Jonne: If there is work to be done, the [netext] group could take the work. [12:51:36] <22NDSTRE-934E1A> Jonne: so it isn't required to have a new WG. [12:52:06] <22NDSTRE-934E1A> Greg: What does the netext2 effort have to show the netext chairs to get the work chartered? [12:52:17] <22NDSTRE-934E1A> Marcelo: What does this group have to show the ADs? [12:52:33] response to gregory: sometimes we can start work based on problem definition. I think in this case we need to both have very clear requirements and choose one of the solution directions from Julien before we can do constructive work in a WG. [12:52:40] <22NDSTRE-934E1A> Jonne: The outcome can still be that there isn't an agreeable set of requirements, or that the requirements can be met by other means. [12:54:04] <22NDSTRE-934E1A> Greg: As George mentioned, maybe it is the case that we already have solutions to the problem? The purpose here today includes finding out whether there is a problem we want to solve, and whether we can understand the requirements to start work. [12:54:16] <22NDSTRE-934E1A> Jonne: Channels Jari's observation to Greg. [12:54:53] HeikkiMahkonen leaves the room [12:55:08] lebobits joins the room [12:55:22] jari, I agree with what you said [12:55:32] This is Gregory (btw) [12:55:56] there is clearly history here with which I am less familiar, and your guidance sounds wise [12:56:09] <22NDSTRE-934E1A> [speaker at mike]: We agreed that LMA has to be able to trigger handovers. We had problem with multihoming - problem should be discussed separately. [12:56:30] vidya leaves the room [12:56:55] <22NDSTRE-934E1A> Subir: is there a requirement that the mobile node should be able to do the flow on a different interface? [12:57:05] <22NDSTRE-934E1A> Rajeev: mext would allow you do to that. [12:57:23] <22NDSTRE-934E1A> Suresh: We need some deployment input. [12:58:12] <22NDSTRE-934E1A> Ryuji: We should identify the requirement. I am not sure if we really agree on multiple access? [12:58:51] my .02: [12:59:26] write a prob statement + requirements document that, per Jari's input, indicates a solution direction of the two posed. [12:59:49] <22NDSTRE-934E1A> Charlie: 3GPP is considering such a solution as has been suggested here. [12:59:57] once that I-D reaches rough consensus, I would guess you'd be on your way. [13:00:00] hope it helps, [13:00:01] Gregory [13:00:07] 22NDSTRE-934E1A leaves the room [13:00:08] YGHONG-X300 leaves the room [13:00:19] HUI leaves the room [13:00:24] S736548CEF7F67 leaves the room [13:00:27] tsavo_work@jabber.org/Meebo leaves the room [13:00:37] sureshk leaves the room [13:00:41] lebobits leaves the room [13:00:41] lebobits joins the room [13:01:06] josoinin leaves the room [13:03:12] anyrhine leaves the room [13:17:25] lebobits leaves the room [13:17:35] alexmcmahon leaves the room [13:18:24] Ralph Droms leaves the room [13:21:37] CHENGANG leaves the room [13:28:07] Desire leaves the room [13:28:39] cjbernardos leaves the room [15:05:15] jariarkko leaves the room