Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt

Hi Craig,

many thanks for your thoughtful review. I am sure the authors and the RG find this useful.

Regards,

-Rajeev

--- On Tue, 3/24/09, Craig Partridge <craig@aland.bbn.com> wrote:

From: Craig Partridge <craig@aland.bbn.com>
Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
To: irsg@ISI.EDU
Date: Tuesday, March 24, 2009, 9:22 AM

I had two almost contradictory views after reviewing the document.

The first view is that it is very well-informed and presents a lot of
complex information well.  The second view is that it seems lost -- that
it doesn't know what it is trying to do and where it is going.

So, I'm comfortable seeing it published -- I think some folks will find
it useful, but have some suggestions for how it could be improved to work
as a roadmap for research/thinking about the problem of multicast
mobility in wireless (which I think is what it aspires to be).

Comments:

    * First, the draft should be more explicit that its focus is
      on multicast IPv6 mobility in WIRELESS environments.  You can read
      the early part of the draft and think you might be involved
      in worrying about someone unplugging from one wired network and plugging
      into wired network.  Particular odd is that Figure 1 clearly
      envisions wireless edge networks (single and multihop) yet never
      says wireless anywhere in the text around it.

      (Example -- "wireless" appears in the abstract but then not
      again until page 8...)

    * The document appears to be seeking to define a set of constraints
      within which a solution must appear.  I took the step of capitalizing
      every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and when you
      do that the document is clearly a half-thought-out requirements
      document.  I suspect the authors would be surprised at themselves if
      they undertook the experiment.

      I mention it because I often reacted that the document was setting
      requirements in one spot but not another and I wondered why.

    * in section 2.1, "jointly support unicast and multicast" -- why
      not broadcast and anycast as well? (esp. as broadcast is
      near universal in wireless and anycast apparently matters)

    * in section 2.2.1, 2nd bullet, why would we enable multicast in
      a network but ban a particular multicast group from circulation?
      (Needs some more explanation here about why this happens -- it is
      a surprising restriction not mentioned earlier).

    * 2.2.2 uses the word "n-casting" in a context where it is clear
      the draft things n-casting is evil, but n-casting is never defined
      anywhere in the document.

    * 2.4 "Facing deployment complexity, it is desirable that any solution for
      mobile multicast SHOULD leave routing protocosl unchanged". [Note
      I capitalized SHOULD to point out the restriction here].  Why is this
      desired?  If we found a routing approach that worked better for all
      environments and supported multicast, wouldn't we prefer that?

    * 4.1 -- never mentions that wireless is inherently a broadcast medium
      and that there may be opportunities to exploit this feature.
      Especially for receivers, an inherently multicast medium makes it
      easier to rejoin groups (if the group is already live, you can
      immediately listen in).

Craig
_______________________________________________
IRSG mailing list
IRSG@mailman.isi.edu
http://mailman.isi.edu/mailman/listinfo/irsg