Re: [multimob] re Adoption of HO drafts incl. draft-schmidt-multimob-fmipv6-pfmipv6-multicast

[Marco Liebsch <[e-mail]>]

Just a side note: As there was already some confusion during Vancouver
meeting and the reference to the transient binding extensions (RFC6058)
still shows up repeatedly, let me clarify one thing:

PFMIP6 and Transient Binding address different use cases, they
have been specified to address different problem spaces. It's 
not appropriate to refer to these two unicast protocol extensions
in the multicast space, in particular not in the context of the
current Multimob discussion whether or not to go for one
selected or 4 protocol specifications.

marco




>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Thomas C. Schmidt
>Sent: Dienstag, 7. August 2012 00:04
>To: liu dapeng
>Cc: [e-mail]
>Subject: Re: [multimob] re Adoption of HO drafts incl. draft-schmidt-
>multimob-fmipv6-pfmipv6-multicast
>
>Hi Dapeng Liu,
>
>On 06.08.2012 00:28, liu dapeng wrote:
>
>>
>> http://tools.ietf.org/html/draft-hui-multimob-fast-handover-04
>>
>>
>>
>>
>> This draft is - if you want so - a competitor to
>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast, but has never been
>> worked out (as have several other attempts in the past). If this
>> document was to be advanced, it had to rewrite (or copy ??) 80 % of
>> our draft, which is not a proper way to treat authorship.
>>
>> ===>
>> I aggree draft-hui-multimob-fast-handover-04 is a competitor of
>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast.  Further more,
>> draft-hui-multimob-fast-handover was written in June 2009 and after
>> this draft was submitted for more than half a year, other similar
>> draft was submitted and have a lot common idea of our draft. So I
>> really do not see why someone say if this document was to be advanced,
>> it will need to "COPY" 80% of
>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast?
>>
>> To Behcet:
>>
>> 1. First of all, may I ask why IETF need more than one solution for
>> one problem?
>> 2. If the group have decided to allow more than one WG draft forthis
>> problem, I then also request the group to consider
>> draft-hui-multimob-fast-handover-04 as one basis of WG document.
>>
>
>Two answers:
>
>  1. There may be several solutions for different scenarios on the same
>problem scope, as the unicast-people worked out several solutions (i.e.,
>MIPSHOP worked out the (P)FMIPv6 handover solution and the transient
>binding in parallel.
>
>  2. draft-hui-multimob-fast-handover-04 has never been worked out. In fact,
>it merely repeats incomplete work that has been around for years, the first
>draft with incomplete sketches on fast handover has been
>http://tools.ietf.org/html/draft-suh-mipshop-fmcast-mip6-00 in 2004!
>
>So the argument we were presenting is: there is reason and need for this fast
>handover solution, and we should adopt the document that is most mature,
>completely worked out and discussed many times in the WG.
>
>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: [phone] °
>° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone]
>°
>_______________________________________________
>multimob mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/multimob