# DO declaration explainer + validator > Paste the JSON you POST to /mgmt/shared/declarative-onboarding and it reads it back: whether it is a DO request wrapper or a bare Device declaration, the top-level options, and the Common tenant's class-objects grouped by the phase DO onboards them in, with every class named and explained. It also checks the structural rules F5 documents and flags the gotchas that bite in production, from the DO 1.36 allowService default change to a root user missing its oldPassword. DO is the sibling of AS3: DO does the L1-L3 onboarding, AS3 the L4-L7 services. - Tool: https://ronutz.com/en/tools/do-explainer-validator - Family: Networking --- # DO declaration explainer + validator Declarative Onboarding is the sibling of AS3, and the split between them is the cleanest way to hold both in your head: AS3 configures the Layer 4-7 application services on a BIG-IP that is already on the network, and DO does the Layer 1-3 onboarding that gets it there. Licensing, module provisioning, DNS and NTP, VLANs and self IPs and routes, user accounts, and the clustering that joins boxes into a high-availability pair are all DO's job. This tool renders each declaration back to you the way the docs describe it. Paste the JSON you POST to `/mgmt/shared/declarative-onboarding` and it first tells you what kind of document it is: a bare `Device` declaration, which is what you send straight to a BIG-IP, or a `class DO` request wrapper carrying a `targetHost`, which is what you send to a BIG-IQ to onboard a device remotely. It reads the top-level options, the `schemaVersion`, `async`, `webhook`, and `label`, and then walks the one tenant a DO declaration is allowed to have, which the schema requires be named `Common`. The walk is grouped by the phase DO effectively onboards in, because the order is the intuition worth carrying: licensing and provisioning gate the modules that everything else depends on, system identity like hostname and DNS and NTP and users is foundational, networking builds the data plane of VLANs and self IPs and routes, and clustering joins the onboarded box to its peers. Every class is named and explained from F5's schema reference, and a class this tool does not recognize is still reported rather than dropped. Three documented gotchas are enforced mechanically rather than left to a footnote. The `hostname` may be set on `Common` or inside a `System` class, but not both, and declaring it twice is flagged. A `SelfIp` that omits `allowService` is flagged with the version note that matters: DO 1.36 changed that default from `default` to `none`, so a self IP that used to inherit management-plus-default-services now allows nothing until you say otherwise. And a `root` user without its `oldPassword` is flagged, because DO cannot change the root password without the existing one. The tool also surfaces the `async` behavior: `async: true` returns a 202 with a task id immediately, and you poll that task with GET until it completes. This is a structure explainer and sanity checker, not a full JSON-Schema validator; F5 publishes the DO schema for VS Code validation, and a declaration that passes here can still be rejected by DO itself. Everything runs locally, nothing you paste leaves the page, and nothing here ever contacts a BIG-IP or a BIG-IQ. ## Standards and references - [F5 BIG-IP DO: Composing a Declaration for a Standalone BIG-IP (the Device/Tenant/Common model, the class list, the standalone example, the hostname mutual-exclusion, the endpoint)](https://clouddocs.f5.com/products/extensions/f5-declarative-onboarding/latest/composing-a-declaration.html) - [F5 BIG-IP DO: Appendix A Schema Reference (the complete class and property catalog, defaults, and per-property version notices including the DO 1.36 allowService change)](https://clouddocs.f5.com/products/extensions/f5-declarative-onboarding/latest/schema-reference.html) - [F5 BIG-IP DO: Composing a Declaration for a Cluster of BIG-IPs (ConfigSync, DeviceGroup, DeviceTrust, FailoverUnicast, and the owner-vs-member semantics)](https://clouddocs.f5.com/products/extensions/f5-declarative-onboarding/latest/clustering.html) - [F5 BIG-IP DO: Network Objects (VLAN, SelfIp with allowService port-lockdown, Route, RouteDomain, and the data-plane classes)](https://clouddocs.f5.com/products/extensions/f5-declarative-onboarding/latest/declarations/network-objects.html) - [F5 BIG-IQ: Declarative Onboarding API reference (the class DO request wrapper and targetHost for remote onboarding)](https://clouddocs.f5.com/products/big-iq/mgmt-api/v0.0/ApiReferences/bigiq_public_api_ref/r_do_onboarding.html) ## Related reading - [Declarative Onboarding: The L1-L3 Half of the Automation Toolchain](https://ronutz.com/en/learn/bigip-declarative-onboarding-do.md): AS3 configures application services on a BIG-IP that is already on the network. Declarative Onboarding is what gets it there: licensing, provisioning, DNS and NTP, VLANs and self IPs and routes, users, and clustering, expressed as one JSON declaration against a Device with a single tenant named Common. This walks the model, the onboarding phases, and the version-specific gotchas that bite in production. - [Telemetry Streaming: The Automation Toolchain Extension That Observes Instead of Configures](https://ronutz.com/en/learn/bigip-telemetry-streaming-ts.md): AS3 configures application services and DO onboards the device. Telemetry Streaming is the third F5 Automation Toolchain extension, and it is the one that observes rather than configures: it aggregates, normalizes, and forwards statistics and events from the BIG-IP to a consumer like Splunk, ElasticSearch, DataDog, or Prometheus, all from one JSON declaration. This walks the Telemetry class model, the source-and-consumer pipeline, and the gaps that make a declaration succeed while collecting nothing.