> -----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
