Hi Thomas, Please see inline.
Regards, Behcet On Wed, Feb 5, 2014 at 12:00 PM, Thomas C. Schmidt < [email protected]> 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 >> [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
