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

[Craig Partridge <[e-mail]>]

All sounds right from my perspective (sorry for delay -- I was on
vacation).

In message <[e-mail]>, "Thomas C. Schmidt" wr
ites:

>Dear Craig,
>
>many thanks again for your review.
>
>We have now discussed and overlooked things, and are ready to answer: 
>please see comments inline.
>
>
>> --- On *Tue, 3/24/09, Craig Partridge /<[e-mail]>/* wrote:
>> 
>> 
>>     From: Craig Partridge <[e-mail]>
>>     Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
>>     To: [e-mail]
>>     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.
>> 
>
>This is in a sense quite right: We are trying to comprehensively explore 
>the problem space and to present all relevant aspects of the somewhat 
>intricate issues. The idea was to write a general reference document 
>that summarizes 'all there is to think about' in its corresponding contexts.
>
>In this sense, the document is not going into a particular direction, 
>that's right.
>
>>     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...)
>> 
>
>Yes, you are right: one should not forget about the obvious.
>
>We added explicit statements in the introduction to link to the wireless 
>domain.
>
>>         * 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.
>> 
>
>We repeated your experiment and questioned all these occurrences. In 
>quite a number of cases we reworded, in particular the "must/must not" 
>terms.
>
>In general the document does not make use of normative terms in the 
>sense of RFC 2119, so there are repeated occurrences where "should" is 
>just used as an English word, in particular like "should preferably do ...".
>
>There are a couple of instances, where requirements drop out of other 
>sources. Some originate for instance from normative aspects of existing 
>standards (e.g., "must respect scoping restrictions"), some are just 
>logical consequences of technical arguments given beforehand (e.g., 
>"source must provide address transparency"). The latter are not meant as 
>requirements for specific protocols, but as conclusions "if we want to 
>achieve this, we have to do the other".
>
>>           I mention it because I often reacted that the document was setting
>>           requirements in one spot but not another and I wondered why.
>> 
>Actually, we tried to keep the solution space as open as possible by 
>avoiding any evitable constraint in argumentation.
>
>>         * 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)
>> 
>:-) The issue we discuss is multicast and thereby assume, a unicast 
>routing is present. Broadcast, I suspect, is not exactly an issue, as it 
>may be viewed as a special case of multicast (can at least be emulated 
>by multicast).
>Anycast matters, yes, but it is not required to implement multicast. So 
>adding anycast mobility aspects to the document would probably just 
>confuse the reader, or am I wrong?
>
>
>>         * 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).
>> 
>We added a clarifying remark.
>A limited group allowance is not rare these days for administrative 
>reasons. A typical example are IPTV deployments, where providers offer 
>(allow for) a certain collection of groups (TV channels) they 
>(contractually) support. Other IPTV multicast groups they do not support 
>(allow) in their networks. So by changing a provider on handover, one 
>may enter a domain without the group previously under subscription.
>
>>         * 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.
>> 
>We added an explanation.
>
>By the way: this is not meant to say n-casting is evil - the document 
>just recalls known issues.
>
>>         * 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?
>> 
>
> From a technical and research perspective we completely agree: We would 
>much rather design an elegant routing protocol than fiddle with proxy 
>functions. However, this is a pure deployment argument. Given the 
>experiences with slow, limited multicast deployment today, it appears 
>much more promising to propose solutions that only require adding some 
>'boxes' at the wireless edges and leave the routing core untouched. 
>Otherwise, we assume, a timely deployment is hardly to expect.
>
>>         * 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).
>> 
>Yes, again this is one of the obvious to be mentioned in the beginning 
>of section 4. We added this.
>
>I hope we got all your comments and hints right.
>
>Best regards,
>
>Thomas
>
>-- 
>
>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: [phone] °
>° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °