Hi Charlie, Honestly, I don't know whether how it would be a feature or not. But I know that the current multicast part is one of the requirements/considerations the DMM should take into account. Actually, we need to think of the reason why it is important. Existing approaches were a "patching-up" style that first, base multicast support design has been made on the reference protocol, then optimizations and extensions have been followed, thus leading to the unnecessities to the reference protocol and the inefficiencies to the network. I think this approach has been O.K. until now because IP mobility support itself and enhancement for unicast has been first. But now I believe we're in the slightly different stage when contemplating the ultimate goals and expected effects by the DMM. So, I think we need to consider the requirement reflecting such a concern at the initial stage. And current multicast requirement does not prevent to appear 'good proposals' but only provides the minimum guidelines of IP multicast deployment in the DMM we want to define.
Best Regards, Seil -----Original Message----- From: Charles E. Perkins [mailto:[email protected]] Sent: Saturday, April 27, 2013 1:13 AM To: Seil Jeon Cc: [email protected] Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello Seil, You suggest that if a feature is not listed as a requirement, it cannot be considered during the evaluation of solution proposals. This is not true. Given the choice of two proposals, the one that meets the requirements and offers the best other features will invariably be chosen. The real danger is in disqualifying good proposals because they fail to offer some feature that should not have been made into a requirement. There is no harm in listing desirable features (like multicast) that would enhance the value of a solution that meets the requirements. Regards, Charlie P. On 4/26/2013 6:18 AM, Seil Jeon wrote: > Hi Charles, > > Actually, in realizing DMM-based mobility management, as you know, > they may exist various ways or more requirements for DMM protocol > deign tackling the issues raised from CMM. Given the requirements > defined in the document is confining, in their ways, explicitly or > implicitly the protocol design for further steps. > It means that proposed solutions should satisfy or consider the > requirements, or they will not be DMM solution in DMM WG at least. > > If you see the mail posted by Sergio a few days ago, the multicast > part title was changed with 'Multicast Considerations' for right > meaning. With the meaning, I think it would go together with the other > requirements. Have a look, please. > > > Regards, > Seil > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Charles E. Perkins > Sent: Thursday, April 25, 2013 1:24 AM > To: [email protected] > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > Hello again folks, > > I can't type in all the editorial suggestions right now, but at least > I wanted to provide some overall comments that cause the document to > seem quite inaccurate in many of its claims. > Here are my general comments. > > - The requirements need to be distinguished from the desirable features. > For instance, section 4.7 describes a desirable feature, not a > requirement. > Moreover, the desirable feature may be unattainable. This is important, > because if feature is *required*, a solution not providing the *required* > feature "must" be considered incomplete and rejected. > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
