As an aside, while the draft name does not appear in the RFC, it _will_ appear in the datatracker entry for the RFC (once the RFC is published). I support Rajeev's suggestion to fix the name of the draft (even though the draft is already at the -03 level).
Bill On 11/27/2012 2:23 PM, Rajeev Koodli (rkoodli) wrote: > > Hi Stig, > > > On 11/27/12 10:53 AM, "Stig Venaas" <[email protected]> wrote: > >> On 11/27/2012 10:19 AM, Rajeev Koodli (rkoodli) wrote: >>> >>> 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. >> >> It's a bit misleading, but the name does not matter much. The RFC won't >> have the draft name mentioned anywhere. > > IMHO, that's not a reason to be sloppy and misleading. > You didn't say what's the issue with using the appropriate draft name? > > >> >> Can't we rather discuss how the two real fast handover drafts meet >> the requirements? > > I admit I am not on this alias much. > > I don't understand what is considered "fast handover" here. > Based on what I have read, it's supposed to be a closed issue, and the WG > is moving on with the WG ID that is called "*-fast-handover-*". > And, I have an issue with this misleading naming suggested/adopted by the > chairs. > Please fix the name. > > That's it! :-) > > -Rajeev > > > > >> >> Stig >> >>> >>> -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-mu >>>>>>>>> lt >>>>>>>>> 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-mu >>>>>>>>> lt >>>>>>>>> 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-m >>>>>>>>> ul >>>>>>>>> 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-mu >>>>>>>>> lt >>>>>>>>> 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 >>> >> > > _______________________________________________ > multimob mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/multimob > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:[email protected] 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
