Hi Sergio, all, |Although the motivation is clear, this seems as a light requirement to |be achieved, in the sense that it can be easily transposed. Do you |have in mind what is a valid "justification" for not addressing multicast?
I think we already discussed this in Atlanta. Multicast support should not become yet-another-reason to delay DMM solutions, let alone the requirements document. And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existing mobility protocols, and compatibility) should be sufficient to cover "multicast support". I copy-paste from the respective motivation sections: "DMM solutions SHOULD target IPv6 as the primary deployment environment." [..] "A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols." I think these two would in general cover also stuff developed in multimob. And, as if this is not sufficient, then REQ5 should close this discussion: "The DMM solution MUST be able to co-exist with existing network deployments and end hosts." Therefore, if you already have multicast services in your domain, the DMM solution should handle them. Now, we did agree in Atlanta to have a quick resolution wrt to multicast, and perhaps explicitly add "REQ7: Multicast support", if the multimob folks can deal with this in an expedient manner. If not, imo, REQs 3/4/5 should more than suffice to cover "multicast support in DMM". Best Regards, Kostas _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
