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

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Fri, 27 March 2009 19:11 UTC

Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28A13A6A6E for <mobopts@core3.amsl.com>; Fri, 27 Mar 2009 12:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level:
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ene70RT0cKOj for <mobopts@core3.amsl.com>; Fri, 27 Mar 2009 12:11:32 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D8C803A6996 for <mobopts@irtf.org>; Fri, 27 Mar 2009 12:11:31 -0700 (PDT)
Envelope-to: mobopts@irtf.org
Received: from dhcp-30fd.meeting.ietf.org ([130.129.48.253]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1LnHTd-000JTu-7P; Fri, 27 Mar 2009 20:12:25 +0100
Message-ID: <49CD24FD.9080704@informatik.haw-hamburg.de>
Date: Fri, 27 Mar 2009 12:11:57 -0700
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Rajeev Koodli <rajeev_koodli@yahoo.com>
References: <174229.33108.qm@web111401.mail.gq1.yahoo.com>
In-Reply-To: <174229.33108.qm@web111401.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: irsg@ISI.EDU, Craig Partridge <craig@aland.bbn.com>, mobopts@irtf.org
Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 19:11:33 -0000

Hi Craig,

many thanks for your fast and highly reflective review: this will 
certainly trigger many reflections on our side, as well.

So we will take a bit of time to think things over again ... and then 
respond in detail.

Thanks again!

Kind regards,

Thomas

Rajeev Koodli wrote:
> 
> 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 </mc/compose?to=IRSG@mailman.isi.edu>
>     http://mailman.isi.edu/mailman/listinfo/irsg
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts

-- 

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 °