My take on this is that if we leave the multicast requirements out (that are very brief already) is an ostrich approach.. pretending there are no multicast to take into account. Having the requirements does not mean we spend all effort dedicated to multicast but at minimum we need to ensure the possible protocol design allows easy inclusion of multicast at some point of time. It is just a basis for good protocol design, not relying on a patchwork later on.
- Jouni (as an individual) On Apr 10, 2013, at 9:05 PM, Stig Venaas <[email protected]> wrote: > On 4/10/2013 8:02 AM, Brian Haberman wrote: >> On 4/9/13 6:10 PM, Behcet Sarikaya wrote: >>> >>> I believe multicast is a distraction to dmm at this moment. >>> >> >> I am curious as to why you call it a distraction. It seems to me that >> having multicast support considered at the beginning of the process is >> much better than trying to bolt it on after the fact. That is the >> reason that I suggested that DMM-related multicast be discussed in DMM. > > This is why I (and I believe a few other people) wanted this in the > requirements document. > > Is your objection that multicast is mentioned at all, or the wording > of the section? > > Stig > >> Could you explain why multicast should not be considered by DMM? >> >> Regards, >> Brian >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
