Thanks for checking. To avoid the confusion, kindly rename the draft appropriately. The draft title and the draft name should be consistent, and not mislead, as it does now.
-Rajeev On 11/27/12 9:24 AM, "Behcet Sarikaya" <[email protected]> wrote: >Hi Rajeev, > >I checked again. >The charter item is about PMIPv6 handover optimizations, not on fast >handover. > >The draft name should have been handover-optimizations not fast-handover. > >Sorry about that because I had suggested this draft name. > >Without realizing that it would cause so much trouble. > >I repeat here again, the draft title did not change and the draft >content is reflected in the title. This is the most important thing. > > >Regards, > >Behcet > >On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) ><[email protected]> wrote: >> >> >> Hi Behcet, >> >> On 11/26/12 1:46 PM, "Behcet Sarikaya" <[email protected]> wrote: >> >>>On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >>><[email protected]> wrote: >>>> Hi Behcet, >>>> >>>> these requirements are for a fast handover solution, i.e., a protocol >>>>that >>>> operates a *handover* in a *fast* manner. >>>> >>>> I agree that draft-ietf-multimob-fast-handover does not meet the >>>> requirements, but had written earlier on the list that the name of >>>>this >>>> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover >>>>is >>>> not a fast handover solution, and (ii) the name "fast handover" is >>>>tied >>>>to >>>> RFC5568/RFC5949-like schemes for good reasons. >>>> >>> >>>The draft title contains ... handover optimization ... and it reflects >>>its content. >>>We asked for this WG draft name because of the charter item to which >>>it corresponds. >> >> Sorry, which charter item has "fast-handover"? >> Could you clarify? >> >> Thanks. >> >> -Rajeev >> >> >> >>> >>>I think this clarifies your confusion. >>> >>>Regards, >>> >>>Behcet >>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> >>>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>>> >>>>> Hi Thomas, >>>>> >>>>> It seems that these requirements are for >>>>> >>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>> >>>>> and not for >>>>> draft-ietf-multimob-fast-handover. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked >>>>>>me to >>>>>> restate requirements of a "fast handover solution" for Multicast >>>>>> Mobility. >>>>>> >>>>>> Here they are: >>>>>> >>>>>> (i) Handover should be fast (this is only true for a direct >>>>>>pMAG/AR >>>>>>to >>>>>> nMAG/AR solution such as >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast). >>>>>> >>>>>> (ii) Multicast handover should be fully synchronized with unicast >>>>>> handover >>>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>>issue >>>>>> for >>>>>> the RAMS-approach, i.e., >>>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>>> >>>>>> (iii) Multicast handover solutions should tightly integrate with >>>>>> unicast >>>>>> handover (only >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast >>>>>> integrates with PFMIPv6 and FMIPv6). >>>>>> >>>>>> (iv) Handover management should reuse standard mobility and >>>>>>multicast >>>>>> protocol operations for easy implementation and deployment >>>>>> >>>>>> >>>>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mul >>>>>>ti >>>>>>cast >>>>>> introduced the use of standard IGMP/MLD records for context >>>>>>description >>>>>> in >>>>>> transfer, which has been copied several times). >>>>>> >>>>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>>>well >>>>>> as >>>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast. >>>>>> >>>>>> Based on these facts, chairs and AD proclaimed to re-decide on >>>>>>future >>>>>> paths >>>>>> for Multimob fast handover solutions. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Thomas >>>>>> -- >>>>>> >>>>>> Prof. Dr. Thomas C. Schmidt >>>>>> ° Hamburg University of Applied Sciences Berliner >>>>>>Tor 7 >>>>>> ° >>>>>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>>>Germany >>>>>> ° >>>>>> ° http://www.haw-hamburg.de/inet Fon: >>>>>>+49-40-42875-8452 >>>>>> ° >>>>>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>>>+49-40-42875-8409 >>>>>> ° >>>>>> _______________________________________________ >>>>>> multimob mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >>>> >>>> -- >>>> >>>> Prof. Dr. Thomas C. Schmidt >>>> ° Hamburg University of Applied Sciences Berliner >>>>Tor >>>>7 ° >>>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>Germany ° >>>> ° http://www.haw-hamburg.de/inet Fon: >>>>+49-40-42875-8452 ° >>>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>+49-40-42875-8409 ° >>>_______________________________________________ >>>multimob mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/multimob >> _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
