Hi, Mobility issues are not specifically in MIF scope. So, as long as we are talking about exposing mobility state, the I-D should be in DMM. Another reason is that MIF is still discussing the generic MIF API, so, I'm not sure they can go on the mobility area before a while.
Pierrick >-----Message d'origine----- >De : dmm [mailto:dmm-boun...@ietf.org] De la part de Zuniga, Juan Carlos >Envoyé : mardi 18 mars 2014 05:08 >À : Sri Gundavelli (sgundave); Jouni Korhonen; dmm@ietf.org >Objet : Re: [DMM] re-charter text updated > >Hi, > >> -----Original Message----- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli >> (sgundave) >> Sent: Monday, March 17, 2014 11:49 PM >> To: Jouni Korhonen; dmm@ietf.org >> Subject: Re: [DMM] re-charter text updated >> >> >> >> On 3/17/14 7:20 PM, "Jouni Korhonen" <jouni.nos...@gmail.com> wrote: >> >> >Folks, >> > >> >Triggered by the question from Behcet, we should come up with the >> >milestones. Few proposals: >> > >> >o The deployment models and scenarios I-D is obvious. >> >o Anchor selection I-D is obvious. Could we also bundle >> > the re-anchoring solution into this one or should it be >> > a different I-D? >> >> >> IMO, these are two different topics and can be kept as separate work >items. >> >> Anchor selection is tied to access network, request path, policy, >handovers >> and load on the target elements. The entity using the gateway >selection can >> be a end point, a network node or a policy system. The bulk of the >work is >> around laying out the considerations for gateway selection and >specifying >> the logic. The selection to most part is about the assigning a gateway >during >> initial session establishment. >> >> Session Re-anchoring is about moving a session state between gateways, >> after the session got established. It has impact on the forwarding >plane and >> is more about a routing problem. But, you may argue this is also >touching >> the aspect of gateway (re)-selection at a failure point. In this sense >there is >> some relation there, but it depends on how the re-anchoring solution >is >> specified. >> >> IMO, its better to track them as separate work items. > >[JCZ] +1 > >> >> >> >o Mobility state exposing I-D. This would communication >> > between the end host and the network. Maybe also covering >> > the missing parts within the end host.. Are we OK with one >> > I-D or how people want to see this? >> >> >> Single ID is fine. > >[JCZ] Single ID is fine indeed. However, we still need to assess whether this >will be a DMM or a MIF ID. > >Regards, > >Juan Carlos > >> >> >> Regards >> Sri >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
