Aah, that would be my next assignment for Protocol Design 101, except that I'm publishing my own solution now :-)
> How does ordering the options make parsing easier? In general, your code, when seeing a later-ordered option, knows whether an earlier-ordered option is in the packet or not -- it cannot occur later. This can simplify code a lot. Of course, that is only the case if the code that is processing one of the options influences the code processing one of the other options. Haven't looked at ND much in this respect. > What does the receiver do if the options are out of order? Discard the whole > message? Yes, please. > How, exactly, would specifying the order make any difference to an > implementation in terms of: > > * code size and complexity Hard to say without actually having written both versions, but I know that I've seen code getting quite a bit simpler that way. > * processing time Negligible, I'd say. > * interoperability Tends to get better, because there are fewer cases to test. Random option ordering is a kind of variability that nobody really needs. (As one historic example of how protocols can be improved by removing that variability, the "&" connector was thrown out of SGML when it became XML.) > Seems to me such a requirement would reduce interoperability with existing > implementations. For protocol like ND, that might be a problem. Whether we want to make this change for 6lowpan depends a lot on whether we think people will write new ND implementations for 6lowpan or reuse old ones. For any new protocol, I would always consider requiring ordering the options. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
