Hi Philip, I think we have strong agreement that code space is at a premium. (There are lots of people who’d rather sell bigger micros than enable the smaller ones, but the point of the whole constrained node network activity is to expand the Internet to less capable platforms.)
There are also limits in what realistically can be achieved; a proper citizen of the Internet does need security, so some minimum capability will be required. Hence RFC 7228. Now how do we get there? When implementing protocols, my experience is that the most expensive “feature” is *having* “features”, i.e., options that can be switched on and off. **It generally costs about the same to handle optionality as it costs to make something mandatory**. That’s why so many things are mandatory in 6LoWPAN — it is much easier to communicate if you can simply rely on a common standard. (We made some mistakes here, such as leaving in the choice to send uncompressed — fixed in later 6lo protocols. We also can argue whether RFC 6282 actually hits the sweet spot between complexity and efficiency. But the decision not to break it up into a zillion of features [except for something relatively expensive such as RFC 7400] was right.) Why didn’t the ecosystems generate pressure to actually implement the standard? We seem to have different perceptions. I stand by my observation that interoperability (except with themselves) wasn’t really an objective in many of the efforts. So parts are left unimplemented. As a WG, 6LoWPAN did little to initiate remedies; e.g., we only ever had one interop event (Berlin 2013). You might say failing to promote interoperability some more was a failure of the chairs, and I couldn’t really disagree. But the ecosystem that was breathing “optimize for grant proposal” instead of “optimize for interoperability” was its own challenge, too. Now how do we solve this? Adding fine-grain optionality to all corners of the protocol is not helping. I think this is where we have very different perception, and I would like to find out why you think it does. I agree that improving diagnostic capabilities would also be useful, so you can find out what is broken. But we disagree on who should bear the burden of dealing with brokenness: I don’t agree that complicating everything else to deal with a broken implementation is the right approach. Keep things simple and fix the brokenness! Grüße, Carsten _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
