Hi Alper, I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases. I found the charter to be broad enough - the current text would support a solution regardless of the specific scenario/design.
But, if it the text is being interpreted in a specific way, I don't have any serious reservations against clarification. Best Regards, John From: Alper Yegin [mailto:[email protected]] Sent: Friday, June 06, 2014 10:53 AM To: John Kaippallimalil Cc: Jouni Korhonen; [email protected] Subject: Re: [DMM] draft charter text updates in github.. Hi John, My reading of that sentence is different. To me it says "We cannot assume that the solutions we are developing would be available on all networks across the Internet". While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK.... and?? In my reading, it does not say the following: "Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this". (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to "anchor re-selection". Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: "Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network." I suppose this clarifies that the "anchor re-selection" can apply to a single session also? BR, John > -----Original Message----- > From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin > Sent: Friday, June 06, 2014 9:38 AM > To: Jouni Korhonen > Cc: [email protected]<mailto:[email protected]> > Subject: Re: [DMM] draft charter text updates in github.. > > Hello Jouni, DMM folks, > > We better clarify what "anchor re-selection" stands for. > If it is about selecting different anchors for different IP flows, that's one > thing. > If it is about changing the IP anchor in the middle of an IP flow, that's > another thing. And that other thing needs to be scoped out. A basic > understanding of a use case would be appreciated (just an explanation for > discussion, I'm not asking for another I-D!), and identification of various > aspects of that scenario which translate to work items for DMM WG. > > I won't be in the call today. So, consider this for a discussion. Follow up on > the mailing list afterwards would be good. > > Cheers, > > Alper > > > > On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: > > > Folks, > > > > Minor changes.. > > > > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > > > IMHO..the charter as it is today, would allow pretty much any solution from > legacy anchoring to herd of pigeons carrying IP.. ;-) > > > > I have put in editorial changes of my own and clear text proposals received > from others. > > > > - Jouni > > > > _______________________________________________ > > dmm mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
