In YANG, how does import differ from include, and what does a submodule's belongs-to statement tie it to?

middlemust knowfreq 22%

answer

other module vs own pieces
namespace stays or is shared
a submodule has one parent
YANG 1.1 relaxed submodule visibility

basics

~20 s

In YANG, import references another module's definitions through a local prefix while that module keeps its own namespace; include merges one of the module's own submodules into it. A submodule's belongs-to names the single module it is part of.

solid answer

~50 s

import makes an external module's top-level typedefs and groupings, its extensions, features and identities, and its schema nodes (as augment/deviation targets or in must, when and path) available, always qualified by the prefix the importer assigns; the imported module stays a separate module with its own namespace, and import chains must not be circular. include is for a module's own submodules: their content is incorporated into the module, shares its namespace, and is seen from outside as one module, so a module MUST include all its submodules. A submodule has no namespace or prefix of its own; its mandatory belongs-to names its parent module and gives a prefix for referring to it. Only that module, or its other submodules, may include it, and the submodule must not import its own module. YANG 1.1 lets a submodule see every sibling submodule's definitions without including them.

`import` makes an *external* module's top-level typedefs and groupings, its extensions, features and identities, and its schema nodes (as `augment`/`deviation` targets or in `must`, `when` and `path`) available, always qualified by the prefix the importer assigns; the imported module stays a separate module with its own namespace, and import chains must not be circular. `include` is for a module's *own* submodules: their content is incorporated into the module, shares its namespace, and is seen from outside as one module, so a module MUST include all its submodules. A submodule has no `namespace` or `prefix` of its own; its mandatory `belongs-to` names its parent module and gives a prefix for referring to it. Only that module, or its other submodules, may include it, and the submodule must not import its own module. YANG 1.1 lets a submodule see every sibling submodule's definitions without including them.

code

yang · 18 lines

yang

module example-routing {
  yang-version 1.1;
  namespace "urn:example:routing";
  prefix ex-rt;
  import ietf-inet-types { prefix inet; }
  include example-routing-static;
  revision 2026-03-01 { description "Initial revision."; }
}

submodule example-routing-static {
  yang-version 1.1;
  belongs-to example-routing { prefix ex-rt; }
  import ietf-inet-types { prefix inet; }
  revision 2026-03-01 { description "Initial revision."; }
  container static-routes {
    leaf next-hop { type inet:ip-address; }
  }
}

go deeper

for a junior

Remember the split: import is for other modules and keeps their namespace, include is for your own submodules and shares yours.

for a middle

Explain what import exposes (top-level typedefs and groupings, identities, features, extensions, schema-tree references) and how belongs-to and its prefix bind a submodule to one module.

for a senior

Show you can debug a split module: missing includes, a submodule importing its own module, version 1 and 1.1 files mixed, and per-file imports that were assumed inherited.

for a principal

Weigh when splitting a large model into submodules pays off against separate modules: one namespace and release cadence versus independent revisions and reuse.

Two linkage statements, two different jobs

YANG (RFC 7950 for version 1.1, RFC 6020 for version 1) has exactly two ways for one file to use definitions from another, and they are not interchangeable:

	`import`	`include`
Argument	the name of another module	the name of a submodule of this module
Namespace of the definitions	stays the imported module's	becomes the including module's
How references are written	always `prefix:name`, with the importer's prefix	as the module's own definitions, under the module's own prefix
Seen from outside	two separate modules	one module
Who may use it	any module or submodule	only the parent module or its submodules
Optional pin	`revision-date` of the imported module	`revision-date` of the submodule

What import gives you

RFC 7950 §7.1.5 lists what an importing module may use:

any grouping and typedef defined at the top level of the imported module or its submodules;
any extension, feature and identity defined there;
any node of the imported module's schema tree in must, path and when expressions, or as the target of augment and deviation.

Import by itself adds nothing to the importer's data tree: nodes appear only when the importer instantiates an imported grouping with uses, or augments the imported module's tree — the augment mechanism belongs to its own subject. Two rules govern the graph that imports form: an external module must be imported to be referenced, and there must not be circular chains of imports ("a" imports "b", "b" imports "a" is illegal). A submodule may import other modules too, but it MUST NOT import its own module.

What include and submodules give you

A submodule is a partial module (RFC 7950 §7.2). It lets an author split a large model into files while keeping a single namespace and a single module identity:

The submodule starts with submodule <name> and must carry belongs-to <module> { prefix <p>; }. That prefix is how the submodule refers to definitions of its module and of the module's other submodules.
It has no namespace and no prefix statement of its own; RFC 7950 says all submodules contribute to the namespace defined by the module.
The parent module lists it with include. RFC 7950 §5.1: a module MUST include all its submodules, and modules may include only submodules that belong to them.
Nothing outside can import a submodule directly — import takes a module name. Outsiders import the module and reach its submodules' top-level groupings and typedefs through it.

Because the module and its submodules are one module externally, the encodings show no seam: the JSON encoding (RFC 7951) qualifies a node defined in a submodule with the name of the main module. RFC 7950 §11 even allows a published module to be split into submodules later, provided its definitions do not change.

What YANG 1.1 changed for submodules

The scoping rule is the difference that bites when you mix versions:

YANG version 1 (RFC 6020): a module had to include a submodule to reference it, and a submodule had to include a second submodule of the same module before referencing its definitions. Circular includes were illegal.
YANG 1.1 (RFC 7950): a submodule can reference all definitions in the module it belongs to and in every submodule the module includes, with no include. A submodule MAY still include siblings for backward compatibility, but it MUST NOT include different revisions than the module does.
Versions do not mix inside one module: a YANG 1.1 module MUST NOT include a version 1 submodule, and a version 1 module MUST NOT include a 1.1 submodule (§12).

RFC 7950 adds two more import-side changes: description and reference are allowed inside import and include, and a module may import several revisions of one module under different prefixes.

Common mistakes

Using include to pull in a general-purpose types module — that module has its own namespace and must be imported.
Expecting a submodule to be reusable by two modules: belongs-to names exactly one parent.
Writing a version 1 style chain of submodule includes in a 1.1 module and believing it is required.

## Two linkage statements, two different jobs YANG (RFC 7950 for version 1.1, RFC 6020 for version 1) has exactly two ways for one file to use definitions from another, and they are not interchangeable: | | `import` | `include` | |---|---|---| | Argument | the name of another **module** | the name of a **submodule** of this module | | Namespace of the definitions | stays the imported module's | becomes the including module's | | How references are written | always `prefix:name`, with the importer's prefix | as the module's own definitions, under the module's own prefix | | Seen from outside | two separate modules | one module | | Who may use it | any module or submodule | only the parent module or its submodules | | Optional pin | `revision-date` of the imported module | `revision-date` of the submodule | ## What import gives you RFC 7950 §7.1.5 lists what an importing module may use: - any **grouping** and **typedef** defined at the top level of the imported module or its submodules; - any **extension**, **feature** and **identity** defined there; - any node of the imported module's schema tree in `must`, `path` and `when` expressions, or as the target of `augment` and `deviation`. Import by itself adds nothing to the importer's data tree: nodes appear only when the importer instantiates an imported grouping with `uses`, or augments the imported module's tree — the augment mechanism belongs to its own subject. Two rules govern the graph that imports form: an external module **must** be imported to be referenced, and there **must not** be circular chains of imports ("a" imports "b", "b" imports "a" is illegal). A submodule may import other modules too, but it MUST NOT import its own module. ## What include and submodules give you A **submodule** is a partial module (RFC 7950 §7.2). It lets an author split a large model into files while keeping a single namespace and a single module identity: 1. The submodule starts with `submodule <name>` and must carry `belongs-to <module> { prefix <p>; }`. That prefix is how the submodule refers to definitions of its module and of the module's other submodules. 2. It has no `namespace` and no `prefix` statement of its own; RFC 7950 says all submodules contribute to the namespace defined by the module. 3. The parent module lists it with `include`. RFC 7950 §5.1: a module MUST include all its submodules, and modules may include only submodules that belong to them. 4. Nothing outside can import a submodule directly — `import` takes a module name. Outsiders import the module and reach its submodules' top-level groupings and typedefs through it. Because the module and its submodules are one module externally, the encodings show no seam: the JSON encoding (RFC 7951) qualifies a node defined in a submodule with the name of the main module. RFC 7950 §11 even allows a published module to be split into submodules later, provided its definitions do not change. ## What YANG 1.1 changed for submodules The scoping rule is the difference that bites when you mix versions: - **YANG version 1 (RFC 6020):** a module had to include a submodule to reference it, and a submodule had to **include** a second submodule of the same module before referencing its definitions. Circular includes were illegal. - **YANG 1.1 (RFC 7950):** a submodule can reference **all** definitions in the module it belongs to and in every submodule the module includes, with no `include`. A submodule MAY still include siblings for backward compatibility, but it MUST NOT include different revisions than the module does. - **Versions do not mix inside one module:** a YANG 1.1 module MUST NOT include a version 1 submodule, and a version 1 module MUST NOT include a 1.1 submodule (§12). RFC 7950 adds two more import-side changes: `description` and `reference` are allowed inside `import` and `include`, and a module may import several revisions of one module under different prefixes. ## Common mistakes - Using `include` to pull in a general-purpose types module — that module has its own namespace and must be imported. - Expecting a submodule to be reusable by two modules: `belongs-to` names exactly one parent. - Writing a version 1 style chain of submodule includes in a 1.1 module and believing it is required.

In a YANG 1.1 module split into three submodules, does each submodule need to include the others to use their groupings?
No. Under RFC 7950 a submodule can reference every definition in its module and in all submodules that module includes; including a sibling is allowed only for compatibility with YANG version 1, where RFC 6020 required it. The module itself must still include all three.
A submodule needs a typedef from a common types module; can it rely on the parent module's import of that module?
No. An import's prefix is scoped to the module or submodule that writes it, so each file that references the types module imports it itself, as the submodule example in RFC 7950 §7.2.3 does.
Why can't two different modules share one submodule?
A submodule's belongs-to names exactly one module, its definitions live in that module's namespace, and RFC 7950 forbids a module from including submodules of another module. Shared definitions belong in a separate module that both import.

Include is binding chapters into one book: they share the book's title and catalogue entry. Import is citing another book: it keeps its own title, and you quote it by a short reference you choose.

saying these in an interview costs you the question

Include and import are interchangeable ways to reuse another module's typedefs.
A submodule has its own namespace that appears in encoded data.
Any module can include a submodule as long as the file is on the search path.
In YANG 1.1 every submodule must include its sibling submodules to use their definitions.
Circular imports are fine as long as both modules pin a revision-date.

In YANG, how does import differ from include, and what does a submodule's belongs-to statement tie it to?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two linkage statements, two different jobs

What import gives you

What include and submodules give you

What YANG 1.1 changed for submodules

Common mistakes

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

Two linkage statements, two different jobs

What import gives you

What include and submodules give you

What YANG 1.1 changed for submodules

Common mistakes

answer

go deeper