Most RFCs define a wire protocol or an algorithm. RFC 7228 does something humbler and arguably more durable: it gives the IETF a shared vocabulary for talking about tiny devices. Before this document, every working group reinvented terms like "small", "embedded", or "low-power", which made cross-WG conversations a mess. Bormann and friends fixed that with a single page of taxonomy that has since been cited by virtually every IoT-adjacent RFC — CoAP, 6LoWPAN, OSCORE, LAKE, SUIT, and so on.

The core contribution: classes of constrained devices. Section 3 defines three buckets based on RAM and flash, the two resources that actually constrain what code you can run:

• Class 0 — <<10 KiB RAM, <<100 KiB flash. Sensors so small they cannot securely talk to the Internet directly; they need a gateway. Think a battery-powered temperature tag.
• Class 1 — ~10 KiB RAM, ~100 KiB flash. Cannot run a full TLS/HTTP/XML stack but can participate in IP networks using protocols designed for them (CoAP, DTLS with carefully chosen ciphersuites). This is the sweet spot CoAP was designed for.
• Class 2 — ~50 KiB RAM, ~250 KiB flash. Can largely run the same code as a server-class node, just with care. A higher-end Cortex-M4 with Wi-Fi.

The numbers were deliberately chosen as orders of magnitude, not exact thresholds, because Moore's Law was expected to push the boundary. Eleven years later the classes still hold up because energy and BOM cost — not transistor density — are the real constraints on the smallest nodes.

The other half: power and network classes. The RFC also defines:

• Power classes P0–P9, from "energy harvesting" (P0) to "always plugged in" (P9). This matters because a device that wakes for 100 ms a day cannot maintain TCP connections or do DTLS handshakes the same way a mains-powered one can.
• Strategies for using power: E0 (event-driven, normally off), E1 (periodic), E2 (always-on). These shape protocol design — e.g., CoAP's Observe option exists because Class 1/E1 devices cannot sit in poll().
• LLN (Low-power Lossy Network) as a category: networks where packet loss is a normal operating condition, not an exception. RPL, the routing protocol for these networks, assumes this from the ground up.

Why a "terminology RFC" matters. When you read a 2024 spec like RFC 9528 (EDHOC), the security analysis is written in terms of "a Class 1 device with a P1 power budget cannot afford X". That shorthand only works because RFC 7228 nailed down the vocabulary a decade earlier. It's the IoT equivalent of RFC 2119's "MUST/SHOULD/MAY" — a tool that disappears into the background but quietly raises the precision of every spec built on top of it.

Backstory. Carsten Bormann (one of the CoAP designers) drove this work because the LWIG and CORE working groups kept arguing past each other about whether a proposed feature was "too heavy". The classes gave reviewers an objective answer: can a Class 1 implementation fit this in 10 KiB of RAM? If no, it doesn't belong in a constrained-device protocol. RFC 7228 was updated by RFC 8352 (2018) to add energy-efficient design considerations, but the original taxonomy is unchanged.