+1 - Ralph
On Jun 28, 2010, at 11:41 AM 6/28/10, Don Sturek wrote: > +1. I don't see any benefit to fixed option encoding. > > Don > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Zach Shelby > Sent: Monday, June 28, 2010 7:47 AM > To: Erik Nordmark > Cc: [email protected] > Subject: Re: [6lowpan] Proposal for ND option order > > Okay, since I started this thread, let me end it. Thanks for the comments > everyone, I think Erik nailed it down here. The only way this could really > reduce code size is if we would have a fixed set of singular MUST options > for each message - but we don't. So let's just drop this idea. > > Zach > > On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: > >> On 06/25/10 05:50 AM, Daniel Gavelle wrote: >>> If there were a fixed number of options with a fixed length and order, >>> the packet would be very simple to parse as the data fields would be at >>> the same offset in the buffer each time. >> >> That would not necessarily be the case, because in many cases the options > are optional, and/or there can be zero or more of them included in a packet. >> >> For example the PIO and 6CIO are of the latter form. >> And ABRO is optional AFAIK. >> There could be a MTU option in RAs. >> Etc. >> >> Erik >> >>> The receiver could check the option type, length and other unchanging >>> bytes at their fixed offsets and if anything doesn't match the fixed >>> values, reject the packet. >>> >>> I think this would save several hundred bytes and make testing simpler. >>> >>> There would need to be two types of e.g. NS, host to LR and LR to LBR >>> but it would be easy to distinguish these. >>> >>> Any future options could be added after the ones that are mandated in >>> the current specification. >>> >>> Daniel. >>> >>> >>> Richard Kelsey wrote: >>>>> From: Ralph Droms <[email protected]> >>>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>>> >>>>> How, exactly, would specifying the order make any difference to an >>>>> implementation in terms of: >>>>> >>>>> * code size and complexity >>>> >>>> If two options interact in any way, the code to process them >>>> is simpler if they appear in a fixed order. The degree to >>>> which a fixed order simplifies the code depends on the >>>> degree of interaction between the various options. >>>> >>>>> * processing time >>>> >>>> No appreciable difference. >>>> >>>>> * interoperability >>>> >>>> Sending the options in the right order, and testing that >>>> they are sent in the right order, is trivial. Testing >>>> that the order in which they appear in incoming messages >>>> is irrelevant is much harder. >>>> >>>>> Seems to me such a requirement would reduce interoperability with >>>>> existing implementations. >>>> >>>> Absolutely. This only makes sense if there are there no existing >>>> deployments. Given the freshness of 6LoWPAN ND >>>> I am not sure that this is an issue. >>>> >>>> -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 > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 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
