+1 Robert Cragie (Pacific Gas & Electric)
Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 28/06/2010 3:46 PM, Zach Shelby wrote:
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. ErikThe 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 complexityIf 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 timeNo appreciable difference.* interoperabilitySending 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
