Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02

[Behcet Sarikaya <[e-mail]>]

Hi Thomas,

Please see inline.

Regards,

Behcet


On Wed, Feb 5, 2014 at 12:00 PM, Thomas C. Schmidt <
[e-mail]> wrote:

> Thanks Behcet,
>
> for enjoying the Superball. Who won?
>
> Seattle Seahawks won, you should have watched the game it was fun :-)
(not like reading your mail, though)


> Regarding the draft, we will provide an update soon that will include
> previous feedback from the WG, as well.
>
> What we already can say right now:
>
>  We won't rip the draft into pieces and turn it into a fragment, as you
> please to suggest. Content, coverage and scope of this draft has been under
> intense discussion since 2010 with two ADs (Jari and Brian) involved. The
> last clear roadmap on the subject was given by Brian in the Berlin meeting.
>
> I don't think Brian made any technical comments on your draft.


> Behcet, every document we have worked out, you tried to destroy at the
> very last minute.
>
>
Wow, this is big claim. Please see below.


>  * For RFC 6224 you requested changes to make it technically completely
> wrong.
>
>
This is an old story.
The comments I made were completely technical, I had even put them in issue
tracker, this was the first and last time the issue tracker was used in
Multimob
 and they were not wrong.
Please go to the list, get my comments and let Multimob know which ones
were wrong, I challenge  you on this, because you always refused to comment
on them.

 * You requested to garble the source draft a couple weeks ago.
>
> Again, I made technical comments. You personally claimed that PIM at MAG
won't work for receiver mobility.
But now you are including in the source mobility draft PIM at MAG case.

Can I ask you what type of deployment policy we are advocating to the
operators?

For receiver mobility you should have Proxy at MAG. You can not have PIM at
MAG.
For source mobility which is much less frequently used case, you should
deploy PIM at MAG?


 * Now you ask for ripping apart the *fmipv6 protocol systematic.
>
>
I just noticed that you included fmipv6 even into the draft name.
This is the same story.
Multimob was chartered to work on PMIPv6 multicast extensions not MIPv6
because MIPv6 already had multicast support.
We called it multicast mobility WG because we wanted to include IGMP/MLD
for mobility cases which we did to some extent.

You seem to feel free to add anything you like to your drafts and if asked
to remove you claim that we are trying to garble your draft.

I don't know why you're doing this ... but it's always against the quality
> of the documents, against the IETF consensus policy ... and it's always
> completely useless.
>
>
I did similar requests to ropt draft, we asked PIM text to be removed and
the authors did remove, they did not claim that their document is being
garbled.

I did similar request to Luis' handover draft, we asked a chunk of the
draft (about 10 pages) to be removed, again, the authors did it and they
did not claim their document is being garbled.

Again let me state it clearly, PIM at MAG sections in source mobility draft
and FMIPv6 and MIPv6 sections in your handover draft are out of scope in
Multimob.



> So let's just forget this part of your Superball-Review.
>
>
Thanks for your nice words.


Regards,

Behcet

> Cheers,
>
> Thomas
>
>
>
> On 03.02.2014 00:39, Behcet Sarikaya wrote:
>
>> Dear all,
>>
>> I finished my review while watching Superball 2014 :-), here it is:
>>
>> - remove MIPv6 from the title
>>
>> Sec. 2
>> In addition, the following terms are
>>     introduced:
>>     where are the terms?
>>
>> Sec. 3.1
>> subnet link
>>     use on of them
>>
>> when the group is
>>     natively received.
>>     What does this mean, please explain
>>
>> As group membership information are
>>     s/are/is
>>
>> Sec. 3.2
>>    FMIPv6 coverage is out of scope as it applies to MIPv6, so remove
>> this section
>>    Other sections may need adjustment based on this
>> Sec. 4.1.1
>>    As FMIPv6 is out of scope, this section needs to be rewritten to
>> cover PFMIPv6 (if any)
>> Section 5
>>    Here you may add one sentence saying that these structures can apply
>> to MIPv6?
>> Sec. 5.3
>>    The size of this option in 8 octets
>>    s/in/is
>>
>> Last but not least, I think the draft finishes without a discussion of
>> why this solution is needed. We need some text on this. I don't know if
>> the reference "FMIPv6-Analysis" could be useful.
>>
>> Regards,
>>
>> Behcet
>>
>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> 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: [phone]°
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone]°
>