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 at aland.bbn.com>/* wrote:
From: Craig Partridge <craig at aland.bbn.com>
Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
To: irsg at 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 at mailman.isi.edu </mc/compose?to=IRSG at mailman.isi.edu>
http://mailman.isi.edu/mailman/listinfo/irsg
------------------------------------------------------------------------
_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
http://www.irtf.org/mailman/listinfo/mobopts
