# High level node descriptor **URL:** \ **Category:** Applications & Usage\ **Created:** [January 8, 2019, 1:05pm UTC](https://forum.opencyphal.org/t/high-level-node-descriptor/318 "2019-01-08T13:05:17Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 28, 2019, 10:58am UTC](https://forum.opencyphal.org/t/high-level-node-descriptor/318/4 "2019-02-28T10:58:39Z")
These are very valuable ideas, but I should introduce a few corrections here. First of all, you seem to have based your reasoning upon the experimental version of the specification, which I boldly call “legacy”, also known as UAVCAN v0. The first stable release which is termed UAVCAN v1.0 differs somewhat from v0; you should familiarize yourself with it here: [https://new.uavcan.org/](https://new.uavcan.org/) (if you have strong feelings about the new logo, please head this way: [PR preparations for the upcoming UAVCAN v1.0 release: new website, new logo](https://forum.opencyphal.org/t/pr-preparations-for-the-upcoming-uavcan-v1-0-release-new-website-new-logo/353)). Important differences between v1 and v0 are that there are no more “data type identifiers”, and that there is native support for data type versioning. A brief but comprehensive recap of the differences is available here, although you may have already read that: [Stockholm Summit recap](https://forum.opencyphal.org/t/stockholm-summit-recap/170) Second of all, UAVCAN is intentionally designed to be very stateless and robust. Specifically this: > \<…\> negotiate, establish a connection and subscribe to things \<…\> …is not about UAVCAN. The only kinds of dynamic negotiation are the plug-and-play node allocation feature (which is optional and is actually somewhat discouraged by the specification!) and automatic configuration of the physical layer (auto bit rate detection, which is also optional). A typical UAVCAN node is ready to work immediately once powered on, which is emphasized in the spec: > **5.2.1 Node initialization** > UAVCAN does not require that nodes undergo any specific initialization upon connection to the bus — a node is free to begin functioning immediately once it is powered up. This is important for UAVCAN because high-reliability applications are among its primary use cases. * * * Other than above, we seem to be on the same page. It might be an interesting exercise to come up with a working PoC of a declarative node generator as you described, where one defines a high-level node logic using DSDL types and some interface definition schema (not necessarily DSDL-based). Further development of this idea is highly welcome. --- _[View the full topic](https://forum.opencyphal.org/t/high-level-node-descriptor/318)._