>-----Message d'origine----- >De : Jouni Korhonen [mailto:[email protected]] >Envoyé : jeudi 20 mars 2014 10:00 >À : SEITE Pierrick IMT/OLN >Cc : Alper Yegin; [email protected] >Objet : Re: [DMM] re-charter text updated > > >On Mar 20, 2014, at 4:44 PM, [email protected] wrote: > >> >> >>> -----Message d'origine----- >>> De : dmm [mailto:[email protected]] De la part de Alper Yegin >>> Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : >>> [email protected] Objet : Re: [DMM] re-charter text updated >>> >>> >>> On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: >>> >>>> >>>> On Mar 20, 2014, at 2:58 PM, Alper Yegin <[email protected]> wrote: >>>> >>>>> Hi Jouni, >>>>> >>>>> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>>>> >>>>>>>> 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? >>>>>>>> o .. >>>>>>>> >>>>>>> >>>>>>> There's the API aspect on the terminal (one I-D), and there is the >>>>>>> MN-network interface ones (e.g., extending RA, DHCP, etc.) >>>>>> >>>>>> >>>>>> So you want an API document? I have some reservations documenting >an >>>>>> APIs as-is. Could this be an extension to RFC5014? I'd see this >>>>>> approach feasible since there are even (partial) implementations of >>>>>> the RFC5014 in popular operating systems. >>>>>> >>>>> >>>>> Yes, we are talking about extensions to source address selection (RFC >>> 5014). >>>> >>>> Ack. >>>> >>>>> >>>>> >>>>>> Then the subsequent thing. Each MN-NW interface would be one >>>>>> document, if I understand the above comment correctly? Which one(s) >to >>> do first? >>>>>> ND or/and DHCP? >>>>>> >>>>> >>>>> Yes. Both. >>>> >>>> Ack. Since we are coming up with I-D numbers, any preference on the >>>> protocols that we patch..? >>>> >>> >>> between ND and DHCP? DHCP.. >>> >> >> I'd say ND first :-)... but, anyway, do we really need two different >documents? Although, container differs, I guess extensions will be the same. > >Second the ND thing ;) > >Why two docs.. DHCP is usually easy going as you can practically shove a flock >of pigeons into it and people are just fine. ND is always a different story ;)
Ok, I got it... > >- JOuni > > > > >> >>> Alper >>> >>> >>>> - Jouni >>>> >>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>>> - JOuni >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>> >>>>>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen >>> <[email protected]> wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> I have updated the charter draft text slightly: >>>>>>>>> https://github.com/jounikor/dmm-re- >>> charter/blob/master/recharter_ >>>>>>>>> draft.txt >>>>>>>>> >>>>>>>>> Basically: >>>>>>>>> >>>>>>>>> Added Sri's comment on PMIPv6 maintenance. >>>>>>>>> Added Alper's comment of location of mobility functions. >>>>>>>>> Added links to other IETF WGs on possible mobility enabling >>> technologies. >>>>>>>>> Added a comment that virtualised network functions are in scope. >>>>>>>>> >>>>>>>>> - Jouni >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> 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. >> _________________________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
