External Challenge for Leshan project
The purpose of this page is to list all known challenges outside the Leshan project itself, but which have an impact (could have an impact in the future ) on it. If you want to discuss about one of this point, please create a dedicated issue. For general comment about the page you can use #1591.
If your are concerned by some point and have a different point of view, let me know, then we will fix this page OR add your point of view.
Leshan 1.x is totally dependent of Californium 2.x which is a coap implementation in Java.
Since Leshan 2.x, we refactor Leshan by adding a new Transport Layer Abstraction but our first class coap(s) endpoints are still based on Californium 3.x.
For now, not really as the library is still maintained, is largely used and works well.
But at mid/long term it could become an issue because AFAWK Californium :
- is maintained by only 1 active committer with limited and not- paid time to work on it.
- has a large and hard to maintain code base and too big scope
- has no plan for big new feature. (E.g. no plan for
coap+tcpsupport) - (subjective?) collaboration with main maintainer is difficult when this is about contributing code.
In other words, good to use now, hard to make evolve and uncertain future.
Transport Layer Abstraction is a first step.
Currently, there is not so much alternative. After some investigations only open-coap/java-coap seems to be an possible alternative.
So we also try to provide a coap endpoint based on it.
java-coap pro :
- Currently maintained by a small team, during their job time at Nordic Semiconductor which is using that library in their nRFCloud platform.
- More simple code and more limited scope (only focus on implementing a
coapjava library) - Support
coap+tcp, - Friendly maintainer, seems to be open about changes.
java-coap con :
- probably less used than californium
- not hosted by an open-source foundation.
We need a good, well-maintained, very active, open-source, CoAP only library for Java, managed by a friendly team (ideally with some RFC authors in it).
For DTLS support of coap(s) protocol we rely on Scandium which part of Californium project. Theoretically it should be possible to use it with something else than Californium but it was mainly created to add coaps support to Californium.
So we can make same answer than above 👆 (coap section).
In addition :
- DTLS 1.3 is clearly not planned.
- for a security protocol implementation the "only 1 maintainer" issue is maybe even more an issue.
Here also the Transport Layer Abstraction is a first step.
But I don't know if there is viable alternative for DTLS...
Some tracks :
- JSSE provide
DTLSsupport at least since Java11 - BountyCastle has "Lightweight APIs for ... DTLS (RFC 6347/ RFC 4347)." (eclipse security opinion about it)
- JNFAJ ?
- Using Native library ? like mbedtls, ...
Note that java-coap are using the mbedtls binding. Main maintainers says : "mbedtls is an actively developed, with many security experts (I happend to work with them in my previous work)."
Full feature (D)TLS support in OpenJDK OR a good, well-maintained, very active, open-source, DTLS only library for Java, managed by a friendly team (ideally with some security expert and RFC authors).
Then this could be reused either with Californium or java-coap or for others coap library or even other use case.
It should also be created with cluster use case in mind.
Currently Leshan uses Californium OR java-coap to support CoAP protocol.
java-coap has no support of OSCORE at all. (but project is open to contribution)
Californium has ongoing development but this move very very slowly.
The code is done by 1 external contributor which have very few time to invest on it. Once Minimal Viable Feature will be ready, I'm not sure this contributor will continue to maintain the code in the long term. This could be an issue especially for Security Feature.
If OSCORE become a MUST-HAVE feature for Leshan it will be an issue.
🤷♀️
coap library supports OSCORE.
I ask myself if it could be possible to have small library with very limited scope which will be OSCORE only. Then this library could be reuse by other coap library to add support of it. (Probably doesn't make sense 🤔)
We regularly face miss-interpretation / ambiguity / inconsistency or design issue in specification/RFC we try to implement.
As we mainly implement LWM2M specification most of our "specification" issues comes from LWM2M and it's really difficult to get clarification OR answer from OMA (LWM2M authors). Some reason of that :
- LWM2M specification is written is a closed way. Only member can see in-development specification, can read discussion between authors, or can see PR. To me member you need to pay and the more you pay the more you have decision power.
- Interaction between OMA authors and LWM2M implementers/users are only done at Github repository - LWM2M for Developers. But authors rarely answer to question and generally this is very slow. Reason seems that authors doesn't have time to do that.
An other issue with LWM2M is that they doesn't provide fix for old version of the specification. Only for the latest.
This slows down development and could lead to some interoperability issue. Some "design" issue can strongly impact real production use case.
We create a page where we explain how to deal with specification issue.
If we could have a Leshan's Friend or a teammate participating to LWM2M meeting as OMA Member, we could get answer quickly ? 🤷♀️
LWM2M specification would be written in an open manner and authors would take time to discuss with the Community.
Community could propose contribution (like PR) to modify/fix the specification.
Contributors could grant author right not based on how much he paid but on much he contributes to the specification.
Leshan would implement the version of the specification which is in progress and could give feedback before release of stable LWM2M version.
Like said Eric Allman :
Perhaps the best situation of all is where the standards and implementations are being developed in parallel. ... ... Ambiguities in the standard were exposed quickly, as were well-meaning features that were unnecessarily difficult to implement.
(Source : The robustness principle reconsidered - Eric Allman)
