Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast.
On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -----Original Message----- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; dmm@ietf.org Subject: Re: [DMM] Multicast requirements > -----Original Message----- > From: Stig Venaas [mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: sarik...@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; > Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> Regards, > >> > >> Behcet _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
