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

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 2 Feb 2014 17:39:22 -0600

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 05 Feb 2014 19:00:25 +0100

Thanks Behcet,

for enjoying the Superball. Who won?

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.

Behcet, every document we have worked out, you tried to destroy at the 
very last minute.

  * For RFC 6224 you requested changes to make it technically completely 
wrong.

  * You requested to garble the source draft a couple weeks ago.

  * Now you ask for ripping apart the *fmipv6 protocol systematic.

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.

So let's just forget this part of your Superball-Review.

Cheers,

Thomas

On 03.02.2014 00:39, Behcet Sarikaya wrote:
>    FMIPv6 coverage is out of scope as it applies to MIPv6, so remove
> this section
>    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
> 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-masked]
> 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 °

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Feb 2014 11:21:43 -0600

Hi Thomas,

Please see inline.

Regards,

Behcet

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

> Seattle Seahawks won, you should have watched the game it was fun :-)
(not like reading your mail, though)

> 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
Wow, this is big claim. Please see below.

>  * For RFC 6224 you requested changes to make it technically completely
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.

>
> 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?

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

> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452°
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409°
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 15 Feb 2014 01:03:34 +0100

Hi Behcet,

thanks for your comments: we have updated and submitted the draft.

Please see answers inline:

> In addition, the following terms are

Oopsi, no further terms. We have cleared this.

>     use on of them

OK - it's subnet now.

>     What does this mean, please explain

This means native multicast packet forwarding (instead of tunneling).

> As group membership information are

Thanks - corrected.

>    The size of this option in 8 octets

Thanks - corrected.

> the reference "FMIPv6-Analysis" could be useful.

This corresponds to a comment made be Georgios. We have added the 
following subsection to the introduction:

1.1.  Use Cases and Deployment Scenarios

    Multicast Extensions for Fast Handovers enable multicast services in
    those domains that operate any of the unicast fast handover protocols
    [RFC5568] or [RFC5949].  Typically, fast handover protocols are
    activated within an operator network or within a dedicated service
    installation.

    Multicast group communication has a variety of dominant use cases.
    One traditional application area is infotainment with voluminous
    multimedia streams delivered to a large number of receivers (e.g.,
    IPTV).  Other time-critical news items like stock-exchange prices are
    commonly transmitted via multicast to support fair and fast updates.
    Both may be mobile and both largely benefit from fast handover
    operations.  Operators may enhance their operational quality or offer
    premium services by enabling fast handovers.

    Another traditional application area for multicast is conversational
    group communication in scenarios like conferencing or gaming, but
    also in dedicated collaborative environments or teams.  Machine-to-
    machine communication in the emerging Internet of Things is expected

Schmidt, et al.          Expires August 19, 2014                [Page 4]

Internet-Draft        Multicast for FMIPv6/PFMIPv6         February 2014

    to generate various additional mobile use cases (e.g., among cars).
    High demands on transmission quality and rapidly moving parties may
    require fast handovers.

    Most of the deployment scenarios above are bound to a fixed
    infrastructure with consumer equipment at the edge.  Today, they are
    thus likely to follow an operator-centric approach like PFMIPv6.
    However, Internet technologies evolve for adoption in
    infrastructureless scenarios at disaster recovery, rescue, crisis
    prevention and civil safety.  Mobile end-to-end communication in
    groups is needed in Public Protection and Disaster Relief (PPDR)
    scenarios, where mobile multicast communication needs to be supported
    between members of rescue teams, police officers, fire brigade teams,
    paramedic teams, command control offices in order to support the
    protection and health of citizens.  These use cases require fast and
    reliable mobile services which cannot rely on operator
    infrastructure.  They are thus predestined to running multicast with
    FMIPv6.

Have a safe trip to Monty Python land!

Thomas