> > How, exactly, would specifying the order make any difference to an > implementation in terms of: > > * code size and complexity > * processing time > * interoperability > > Seems to me such a requirement would reduce interoperability with existing > implementations. > > - Ralph > [SC>]
Given that each ND option has unique type and the specified len field, I am not sure how ordering would benefit the implementation as well. In most implementations, a 'for loop' checking for the type in 'case statements' work. I am also interested to find out if it does not work in some embedded systems or what exactly is the issue. Also, I do see the concern on interoperability - i,e I am not sure that the extra effort of standardizing the order would bring any benefit considering the interop issues with existing implementations of IPv6 ND (rfc 4861 and other rfcs) options and more options added in the future. Thanks, -Samita > On Jun 23, 2010, at 1:58 PM 6/23/10, Richard Kelsey wrote: > > >> From: Zach Shelby <[email protected]> > >> Date: Tue, 22 Jun 2010 14:51:32 +0300 > >> > >> I have a proposal to make ND message processing simpler. RFC4861 and > >> 6lowpan-nd-10 don't specify any specific order in which options are > >> to be included, making parsing more complex. We could simplify things > >> by specifying the order options in the NS, NA, RS, RA messages MUST > >> be carried. > > > > If nothing else, specifying the order is likely to reduce > > interoperation problems. Requiring that they be in order of > > increasing Type would be simplest. > > Seems like a good idea. > > -Richard Kelsey > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
