coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1ed7198ce3c0eac1a04124f33e202dcac727acdf
info-tech-canon/seeds/InfoTechCanonNetworkModel_RC1_seed.md

52 KiB
Executable File
Raw Blame History

InfoTechCanon Network Model

Short Name: ITC-NET
Document Status: Seed Standard Release Candidate 1
Version: RC1-seed
Date: 2026-05-23
Repository Context: info-tech-canon
Document Type: InfoTechCanon Domain Standard
Intended Audience: Network architects, platform engineers, cloud engineers, security architects, SREs, DevSecOps teams, service owners, infrastructure operators, zero-trust designers, network automation engineers, knowledge-system builders, and agentic tooling.

1. Purpose

The InfoTechCanon Network Model defines a canonical seed model for representing networks, addressing, topology, connectivity, routing, policy, intent, reachability, flow, segmentation, exposure, and network state across physical, virtual, cloud, Kubernetes, service-mesh, hybrid, and zero-trust environments.

It exists to prevent the network domain from being collapsed into generic infrastructure, security, or access-control models.

This standard provides a canonical vocabulary for:

  • network domains,
  • fabrics,
  • sites,
  • zones,
  • segments,
  • subnets,
  • prefixes,
  • addresses,
  • DNS,
  • devices,
  • interfaces,
  • links,
  • circuits,
  • paths,
  • routes,
  • route tables,
  • peering,
  • NAT,
  • gateways,
  • firewalls,
  • load balancers,
  • ingress,
  • endpoints,
  • flows,
  • reachability,
  • network policies,
  • network intents,
  • network configurations,
  • network state,
  • exposure,
  • segmentation,
  • and source-of-truth boundaries.

2. Position in InfoTechCanon

The Network Model is a domain standard within InfoTechCanon.

It depends on the existing seed standards as follows:

Landscape      = services, runtime resources, environments, infrastructure context.
Organization   = network owners, operators, stewards, accountable teams.
Governance     = network policies, controls, exceptions, evidence, reviews.
Task           = network changes, incidents, remediation, review work.
Tagging        = lightweight classification of network entities and policies.
Access Control = who may administer or use network resources.
Security       = exposure, attack paths, segmentation, network findings.
Data           = data movement, residency, data flows, data access patterns.
DevSecOps      = network configuration as code, deployment, validation, evidence.
Network        = addressing, topology, connectivity, routing, reachability, network policy, intent, and state.

InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel
├── InfoTechCanonOrganizationModel
├── InfoTechCanonGovernanceModel
├── InfoTechCanonTaskModel
├── InfoTechCanonTaggingStandard
├── InfoTechCanonAccessControlModel
├── InfoTechCanonSecurityModel
├── InfoTechCanonDataModel
├── InfoTechCanonDevSecOpsModel
├── InfoTechCanonNetworkModel          <-- this standard
├── InfoTechCanonObservabilityModel
├── InfoTechCanonPatternLanguage
└── Application Profiles

3. Boundary with Adjacent Standards

3.1 Boundary with Landscape

The Landscape Model owns broad runtime and infrastructure context:

Environment
RuntimePlatform
RuntimeResource
ApplicationService
TechnicalService
Endpoint reference
DeploymentRecord

The Network Model owns network-specific structure and behavior:

NetworkDomain
NetworkFabric
NetworkSegment
Prefix
IPAddress
Interface
Link
Route
Path
Flow
NetworkPolicy
NetworkIntent
Exposure
Reachability

Boundary rule:

Landscape owns where systems live and how services relate.
Network owns how communication, addressing, routing, topology, policy, and reachability work.

3.2 Boundary with Security

The Security Model owns:

Threat
ExposureFinding
AttackPath
SecurityFinding
Mitigation
SecurityIncident

The Network Model owns:

Exposure
Reachability
Path
Flow
NetworkPolicy
Segmentation
NetworkState

Security may analyze Network concepts to identify exposure, attack paths, and findings.

3.3 Boundary with Access Control

Access Control owns authorization semantics:

Subject
Permission
Privilege
Grant
AuthorizationDecision
AccessSession

Network owns connectivity semantics.

Example:

Access Control determines whether a subject may administer a firewall rule.
Network determines what traffic the firewall rule permits or denies.

3.4 Boundary with Governance

Governance owns policies, controls, exceptions, evidence, and reviews.

Network owns network policy as technical traffic-control semantics while referencing governance policies as sources or constraints.

Example:

Governance Policy: production databases must not be internet reachable.
Network Policy: deny inbound traffic to database segment except from application segment.

3.5 Boundary with Data

Data owns semantic data flows, datasets, classification, residency, and processing purpose.

Network owns technical packet/service flows and reachability paths.

Boundary rule:

DataFlow describes movement of data meaning.
NetworkFlow describes communication between endpoints.

3.6 Boundary with DevSecOps

DevSecOps owns delivery of network configuration, IaC, policy-as-code, tests, scans, and deployment records.

Network owns the intended, declared, applied, and observed network model being delivered or changed.

4. Research Basis and External Alignment

This seed standard draws on multiple network-management and infrastructure bodies of knowledge.

4.1 YANG and NETCONF/RESTCONF

YANG provides a modeling language for network configuration data, state data, RPCs, and notifications. It is a central mapping target for network configuration and state models.

4.2 Network Management Datastore Architecture

NMDA distinguishes datastore viewpoints such as intended configuration and operational state. This strongly influences the InfoTechCanon Network State Model.

4.3 IETF Network Topology Models

RFC 8345 defines a generic YANG model for network and network topology concepts such as networks, nodes, links, and termination points. Layer-specific topology models extend this idea.

4.4 Intent-Based Networking

Intent-Based Networking clarifies the distinction between intent, policy, configuration, and network behavior. InfoTechCanon uses intent as an abstract desired network outcome, not as a synonym for policy.

4.5 NetBox and Network Source of Truth

NetBox-style source-of-truth practice emphasizes intended-state inventory, IPAM, DCIM, device/interface/cabling modeling, and automation integration. This informs the Network Inventory and Source-of-Truth patterns.

4.6 Kubernetes NetworkPolicy and Cloud-Native Networking

Kubernetes NetworkPolicy models ingress and egress traffic control for selected pods. Cloud-native networking introduces workload identity, ephemeral endpoints, service discovery, ingress controllers, network policies, service mesh, and overlay networking.

4.7 Zero Trust Architecture

Zero Trust shifts focus away from implicit trust in network location toward resource-centric protection, continuous verification, identity, context, least privilege, and policy enforcement close to resources. The Network Model must therefore support network segmentation without assuming that segment location alone establishes trust.

4.8 Cloud Networking and Software-Defined Networking

Cloud networking adds VPC/VNet, subnets, route tables, security groups, network ACLs, load balancers, private links, peering, gateways, NAT, transit networks, and managed DNS as first-class network objects.

5. Seed Standard Design Stance

This standard is a seed standard, not a vendor-specific network schema.

It shall:

  1. define canonical network semantics,
  2. distinguish inventory, addressing, topology, routing, policy, intent, flow, reachability, exposure, configuration, and state,
  3. support physical, virtual, cloud, Kubernetes, service-mesh, and hybrid networks,
  4. support intended, declared, applied, observed, historical, and assessed network state,
  5. support network source-of-truth integration,
  6. support network policy and intent without collapsing them,
  7. support security exposure and zero-trust analysis,
  8. map to external standards and tools without becoming subordinate to them,
  9. remain markdown-first and agent-retrievable,
  10. and support future assimilation of network standards, products, and operational practices.

6. Scope

6.1 In Scope

This standard covers canonical representation of:

  • network domains,
  • fabrics,
  • sites,
  • regions,
  • zones,
  • network segments,
  • subnets,
  • prefixes,
  • IP addresses,
  • DNS zones,
  • DNS records,
  • VLANs,
  • VRFs,
  • overlays,
  • underlays,
  • devices,
  • routers,
  • switches,
  • firewalls,
  • load balancers,
  • gateways,
  • WAFs,
  • proxies,
  • interfaces,
  • ports,
  • links,
  • cables as references,
  • circuits,
  • paths,
  • route tables,
  • routes,
  • BGP/peering references,
  • NAT,
  • service endpoints,
  • ingress,
  • egress,
  • network flows,
  • observed flows,
  • reachability,
  • exposure,
  • network policy,
  • firewall rules,
  • ACLs,
  • security groups,
  • Kubernetes NetworkPolicies,
  • service mesh policies,
  • zero-trust network access references,
  • network intent,
  • network configuration,
  • and network state.

6.2 Out of Scope

This standard does not fully define:

  • all packet formats,
  • every routing protocol detail,
  • full network-device configuration syntax,
  • physical cabling/DCIM in complete detail,
  • complete telecom resource modeling,
  • complete SD-WAN vendor models,
  • all firewall vendor rule models,
  • full Kubernetes CNI implementation,
  • all service mesh internals,
  • all network telemetry metrics,
  • or detailed network security incident response.

Those may be mapped, assimilated, profiled, or handled by adjacent standards.

7. Normative Language

The following terms are used normatively:

  • SHALL indicates a mandatory rule for conformance.
  • SHOULD indicates a recommended practice.
  • MAY indicates an optional capability.
  • MUST NOT indicates a prohibited practice.
  • SEED marks a concept defined provisionally here but open to later refinement.
  • EXTRACT marks a concept that may later move to a more specialized standard.

8. Core Principles

8.1 Network Is More Than Devices

The network includes topology, addressing, routing, policy, reachability, flows, exposure, intent, and state.

8.2 Addressing Is Not Topology

An IP prefix or subnet is not the same thing as a physical, virtual, or logical topology.

8.3 Policy Is Not Intent

Intent describes desired outcomes.

Policy expresses formal allowed, denied, required, or constrained behavior.

Configuration implements policy or intent.

Observed state shows what is actually happening.

8.4 Declared State Is Not Observed State

The model SHALL distinguish intended, declared, applied, observed, historical, and assessed network state.

8.5 Reachability Is First-Class

Whether one endpoint can reach another endpoint is a modelable fact or claim, not merely an inference hidden inside configuration.

8.6 Exposure Is First-Class

A reachable or discoverable surface matters even when no vulnerability is known.

8.7 Source of Truth Must Be Explicit

Profiles SHOULD declare source-of-truth boundaries for inventory, intended configuration, applied configuration, observed state, topology, and flows.

8.8 Zero Trust Changes Network Assumptions

Network segment membership alone SHOULD NOT be treated as sufficient trust.

Resource, identity, policy, context, and access-control semantics may be needed.

8.9 External Standards Are Mapped, Not Obeyed

The Network Model MAY map to YANG, IETF topology models, NetBox, Kubernetes NetworkPolicy, cloud provider network models, firewall models, and zero-trust frameworks.

It MUST NOT subordinate its internal semantics to any single external model.

9. Canonical Seed Metadata

Every network artifact SHOULD support structured metadata.

Recommended front matter:

---
id: itc-net:NetworkSegment
type: concept
standard: InfoTechCanonNetworkModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonNetworkModel
preferred_label: Network Segment
related:
  - itc-net:Subnet
  - itc-net:NetworkZone
  - itc-net:NetworkPolicy
  - itc-sec:Exposure
mappings:
  - itc-map:network-segment-to-netbox-vlan-prefix
---

Recommended artifact statuses:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

10. Root Network Taxonomy

NetworkEntity
├── NetworkScopeEntity
│   ├── NetworkDomain
│   ├── NetworkFabric
│   ├── NetworkSite
│   ├── NetworkRegion
│   ├── NetworkZone
│   ├── TrustZoneReference
│   └── NetworkTenant
├── AddressingEntity
│   ├── AddressFamily
│   ├── Prefix
│   ├── Subnet
│   ├── IPAddress
│   ├── IPAllocation
│   ├── DNSZone
│   ├── DNSRecord
│   ├── Hostname
│   └── ServiceName
├── TopologyEntity
│   ├── NetworkNode
│   ├── NetworkDevice
│   ├── Router
│   ├── Switch
│   ├── Firewall
│   ├── Gateway
│   ├── LoadBalancer
│   ├── Proxy
│   ├── Interface
│   ├── Port
│   ├── Link
│   ├── Circuit
│   ├── Path
│   └── TerminationPoint
├── SegmentationEntity
│   ├── NetworkSegment
│   ├── VLAN
│   ├── VRF
│   ├── OverlayNetwork
│   ├── UnderlayNetwork
│   ├── SecurityZone
│   └── Microsegment
├── RoutingConnectivityEntity
│   ├── RouteTable
│   ├── Route
│   ├── NextHop
│   ├── Peering
│   ├── TransitGatewayReference
│   ├── NAT
│   ├── PrivateLinkReference
│   └── ConnectivityService
├── EndpointEntity
│   ├── Endpoint
│   ├── ServiceEndpoint
│   ├── IngressEndpoint
│   ├── EgressEndpoint
│   ├── PublicEndpoint
│   ├── PrivateEndpoint
│   ├── WorkloadEndpoint
│   └── ManagementEndpoint
├── PolicyIntentEntity
│   ├── NetworkIntent
│   ├── NetworkPolicy
│   ├── FirewallRule
│   ├── ACL
│   ├── SecurityGroup
│   ├── NetworkACL
│   ├── KubernetesNetworkPolicy
│   ├── ServiceMeshPolicy
│   └── TrafficPolicy
├── FlowReachabilityEntity
│   ├── NetworkFlow
│   ├── ObservedFlow
│   ├── AllowedFlow
│   ├── DeniedFlow
│   ├── ReachabilityClaim
│   ├── ReachabilityTest
│   ├── Exposure
│   └── AttackSurfaceReference
└── NetworkStateEntity
    ├── NetworkConfiguration
    ├── IntendedNetworkState
    ├── DeclaredNetworkState
    ├── AppliedNetworkState
    ├── ObservedNetworkState
    ├── HistoricalNetworkState
    ├── AssessedNetworkState
    ├── Drift
    └── ReconciliationResult

11. Core Concepts

11.1 NetworkEntity

A NetworkEntity is any identifiable concept used to represent network structure, addressing, topology, connectivity, routing, policy, intent, reachability, flow, exposure, configuration, or state.

Recommended attributes:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:

Optional attributes:

owner:
steward:
network_domain:
environment:
source_confidence:
valid_from:
valid_to:
tags:
external_references:

11.2 NetworkDomain

A NetworkDomain is a bounded network scope with shared management, policy, addressing, routing, topology, or trust assumptions.

Examples:

enterprise WAN
datacenter network
cloud VPC/VNet
Kubernetes cluster network
service mesh
tenant network
management network
partner network

11.3 NetworkFabric

A NetworkFabric is a coordinated network substrate providing connectivity across nodes, devices, or workloads.

Examples:

datacenter fabric
cloud fabric
SD-WAN fabric
service mesh fabric
Kubernetes overlay

11.4 NetworkSite

A NetworkSite is a physical or logical site relevant to network deployment.

Examples:

datacenter
office
edge location
cloud region site
branch
campus

11.5 NetworkRegion

A NetworkRegion is a geographic, cloud, or provider region relevant to network placement, routing, residency, or operations.

11.6 NetworkZone

A NetworkZone is a logical or physical zone with shared policy, trust, exposure, routing, or segmentation assumptions.

11.7 TrustZoneReference

A TrustZoneReference is a reference to a trust or security zone concept.

Security owns trust evaluation. Network owns the network zone and segmentation structure.

11.8 NetworkTenant

A NetworkTenant is a tenant-specific network scope.

Examples:

customer tenant VPC
namespace-scoped network
project network
organization network

11.9 AddressFamily

An AddressFamily identifies an addressing family.

Examples:

IPv4
IPv6
MAC
DNS
URI
service identity

11.10 Prefix

A Prefix is an address range.

Examples:

10.0.0.0/24
2001:db8::/32

11.11 Subnet

A Subnet is a logical subdivision of an address space, usually associated with routing, placement, and policy.

Canonical rule:

Subnet SHOULD NOT be treated as identical to SecurityZone.

11.12 IPAddress

An IPAddress is an address assigned, reserved, observed, or available within an address family and prefix.

11.13 IPAllocation

An IPAllocation is the assignment or reservation of an IP address or prefix to an entity.

11.14 DNSZone

A DNSZone is an administrative namespace for DNS records.

11.15 DNSRecord

A DNSRecord maps a name to an address, alias, service, or other DNS data.

11.16 Hostname

A Hostname is a network name assigned to a host, endpoint, or service.

11.17 ServiceName

A ServiceName is a name used to discover or address a service.

11.18 NetworkNode

A NetworkNode is an entity participating in a network topology.

Examples:

router
switch
firewall
host
virtual appliance
gateway
workload
service-mesh proxy
cloud network object

11.19 NetworkDevice

A NetworkDevice is a physical or virtual device primarily responsible for network functions.

11.20 Router

A Router is a network node that forwards traffic between networks based on routing information.

11.21 Switch

A Switch is a network node that forwards traffic within a layer-2 domain or switching fabric.

11.22 Firewall

A Firewall is a network node or policy enforcement function controlling traffic according to rules or policy.

11.23 Gateway

A Gateway is a network node or service that connects networks, protocols, zones, or domains.

Examples:

internet gateway
NAT gateway
API gateway
transit gateway
VPN gateway
service mesh gateway

11.24 LoadBalancer

A LoadBalancer distributes traffic across backend endpoints or services.

11.25 Proxy

A Proxy intermediates network communication.

Examples:

forward proxy
reverse proxy
service mesh sidecar
egress proxy
identity-aware proxy

11.26 Interface

An Interface is a physical, virtual, or logical network attachment point of a node.

11.27 Port

A Port is a physical or logical interface endpoint or protocol-level transport port, depending on profile.

Profiles MUST distinguish device port from transport port where both occur.

11.28 Link

A Link is a direct or modeled connection between termination points, interfaces, nodes, or segments.

11.29 Circuit

A Circuit is a provider or transport connectivity service between sites, networks, or endpoints.

11.30 Path

A Path is a sequence of nodes, links, hops, segments, or policies through which traffic may or does travel.

11.31 TerminationPoint

A TerminationPoint is a point on a network node where links terminate.

This concept maps naturally to IETF topology models.

11.32 NetworkSegment

A NetworkSegment is a bounded logical or physical portion of a network with shared connectivity or policy assumptions.

Examples:

VLAN
subnet
microsegment
service mesh scope
security group domain
namespace network

11.33 VLAN

A VLAN is a layer-2 segmentation construct.

11.34 VRF

A VRF is a routing table or routing context allowing multiple routing domains to coexist.

11.35 OverlayNetwork

An OverlayNetwork is a virtual network built over another network.

11.36 UnderlayNetwork

An UnderlayNetwork is the lower-level network providing connectivity for an overlay.

11.37 SecurityZone

A SecurityZone is a zone defined by security policy, exposure, control, or trust assumptions.

Security owns security posture; Network owns segmentation mechanics.

11.38 Microsegment

A Microsegment is a small policy-enforced segment, often based on workload, identity, label, or service context.

11.39 RouteTable

A RouteTable is a set of routes used to determine forwarding or reachability.

11.40 Route

A Route is a forwarding rule mapping destination prefixes or conditions to next hops or actions.

11.41 NextHop

A NextHop is the next network node, gateway, interface, or target for a route.

11.42 Peering

Peering is a connectivity relationship between networks or routing domains.

11.43 NAT

NAT is address or port translation between network scopes.

11.44 ConnectivityService

A ConnectivityService is a service that provides connectivity.

Examples:

VPN
private link
transit network
leased line
SD-WAN service
service mesh connectivity

11.45 Endpoint

An Endpoint is an addressable or reachable network surface for a resource, service, workload, or device.

11.46 ServiceEndpoint

A ServiceEndpoint is an endpoint representing a service.

11.47 IngressEndpoint

An IngressEndpoint is an endpoint through which traffic enters a scope.

11.48 EgressEndpoint

An EgressEndpoint is an endpoint through which traffic leaves a scope.

11.49 PublicEndpoint

A PublicEndpoint is reachable from a public or external network scope.

Public does not necessarily mean unauthenticated.

11.50 PrivateEndpoint

A PrivateEndpoint is reachable only from defined private or internal network scopes.

Private does not automatically mean trusted.

11.51 WorkloadEndpoint

A WorkloadEndpoint is an endpoint associated with a workload, pod, container, VM, function, or service instance.

11.52 ManagementEndpoint

A ManagementEndpoint is an endpoint used for administration, configuration, monitoring, or maintenance.

Management endpoints SHOULD be treated as sensitive.

11.53 NetworkIntent

A NetworkIntent is a declarative desired outcome for network behavior or properties, without specifying all implementation details.

Examples:

Production databases must not be reachable from the internet.
Service A may call Service B over HTTPS.
All management endpoints require private administrative access.
EU tenant traffic must remain in EU regions.

Canonical rule:

NetworkIntent MUST NOT be treated as identical to NetworkPolicy or NetworkConfiguration.

11.54 NetworkPolicy

A NetworkPolicy is a formal statement of allowed, denied, required, or constrained network behavior.

Examples:

allow ingress from frontend to backend on TCP 443
deny egress from database subnet to internet
allow pod selector app=api to connect to pod selector app=db on port 5432

11.55 FirewallRule

A FirewallRule is a traffic-control rule implemented by a firewall or firewall-like enforcement point.

11.56 ACL

An ACL is an access-control list controlling traffic or resource access.

In the Network Model, ACL refers to network traffic control unless mapped otherwise.

11.57 SecurityGroup

A SecurityGroup is a cloud or platform traffic-control construct associated with resources or interfaces.

11.58 NetworkACL

A NetworkACL is a network-level access-control list, often associated with subnets or network boundaries.

11.59 KubernetesNetworkPolicy

A KubernetesNetworkPolicy is a Kubernetes policy controlling ingress and/or egress traffic for selected pods.

11.60 ServiceMeshPolicy

A ServiceMeshPolicy is a policy controlling service-to-service traffic, often involving identity, mTLS, routing, authorization, or telemetry.

11.61 TrafficPolicy

A TrafficPolicy controls routing, splitting, retry, timeout, failover, mirroring, or other traffic-management behavior.

11.62 NetworkFlow

A NetworkFlow is a modeled communication relation from source to destination using protocol, port, service, or application context.

Recommended attributes:

source:
destination:
protocol:
port:
direction:
purpose:
state_context:

11.63 ObservedFlow

An ObservedFlow is a flow detected from telemetry, logs, traces, packet data, flow records, or runtime observation.

11.64 AllowedFlow

An AllowedFlow is a flow permitted by policy or configuration.

11.65 DeniedFlow

A DeniedFlow is a flow denied by policy, configuration, or enforcement.

11.66 ReachabilityClaim

A ReachabilityClaim is an assertion that one entity can or cannot reach another entity under defined conditions.

Reachability claims SHOULD include state context and evidence where possible.

11.67 ReachabilityTest

A ReachabilityTest is an execution or analysis used to determine reachability.

Examples:

ping
TCP connect
synthetic transaction
path analysis
firewall simulation
cloud reachability analyzer
service mesh test

11.68 Exposure

Exposure is a condition where an endpoint, service, network path, or resource is reachable, discoverable, or accessible from a relevant source scope.

Exposure can be intended, unintended, public, private, partner-facing, management-only, or internal.

11.69 AttackSurfaceReference

An AttackSurfaceReference points to security analysis of exposed network surfaces.

Security owns attack surface and attack path analysis; Network owns exposure and reachability facts.

11.70 NetworkConfiguration

A NetworkConfiguration is a declared, applied, or observed set of network settings.

11.71 IntendedNetworkState

IntendedNetworkState is the network state intended by architecture, design, policy, intent, or source of truth.

11.72 DeclaredNetworkState

DeclaredNetworkState is network state declared in configuration, IaC, manifests, controller input, or device configuration sources.

11.73 AppliedNetworkState

AppliedNetworkState is network state accepted and applied by a network device, controller, cloud control plane, Kubernetes CNI, firewall, or service mesh.

11.74 ObservedNetworkState

ObservedNetworkState is network state inferred or measured from runtime observation.

11.75 HistoricalNetworkState

HistoricalNetworkState is network state that was true or asserted at a past time.

11.76 AssessedNetworkState

AssessedNetworkState is derived from analysis, verification, risk assessment, exposure analysis, or compliance evaluation.

11.77 Drift

Drift is divergence between intended, declared, applied, observed, or assessed state.

11.78 ReconciliationResult

A ReconciliationResult records the result of comparing and reconciling different state views.

12. Core Relationship Vocabulary

Recommended root relationship types:

contains
part_of
assigned_to
allocated_to
resolves_to
routes_to
forwards_to
connected_to
terminates_at
attached_to
belongs_to
peered_with
translated_by
exposes
reachable_from
reachable_to
permits
denies
requires
implements
realizes
configured_by
applied_to
observed_as
drifts_from
verified_by
evidenced_by
maps_to

Relationship records SHOULD support:

id:
relationship_type:
source_entity:
target_entity:
scope:
state_context:
valid_from:
valid_to:
source_system:
confidence:
evidence:
rationale:

13. Network State Model

13.1 State Contexts

Required network state contexts:

intended
declared
applied
observed
historical
assessed

13.2 Configuration States

draft
declared
validated
applied
partially_applied
failed
rolled_back
superseded
retired

13.3 Reachability States

unknown
intended_allowed
intended_denied
declared_allowed
declared_denied
observed_allowed
observed_denied
conflicting
indeterminate

13.4 Exposure States

unknown
not_exposed
internal_exposed
partner_exposed
public_exposed
management_exposed
unintended_exposure
accepted_exposure
mitigated_exposure

13.5 Drift States

no_drift
declared_vs_applied_drift
intended_vs_declared_drift
applied_vs_observed_drift
policy_vs_observed_drift
unresolved_drift
accepted_drift

14. Network Patterns

14.1 Pattern: Intent-Policy-Configuration-State Split

Context: Network automation or governance requires clarity about what should happen and what is happening.

Problem: Teams confuse intent, policy, configuration, and observed state.

Solution:

NetworkIntent
  -> NetworkPolicy
  -> NetworkConfiguration
  -> AppliedNetworkState
  -> ObservedNetworkState
  -> AssessedNetworkState

14.2 Pattern: Source-of-Truth Boundary

Context: Multiple tools hold network data.

Problem: Inventory, configuration, telemetry, and policy tools disagree.

Solution: Declare source-of-truth boundaries.

Example:

NetBox owns intended IPAM/DCIM inventory.
Git owns declared network configuration.
Cloud control plane owns applied cloud network state.
Flow logs own observed flows.
Reachability analyzer owns assessed reachability.

14.3 Pattern: Addressing Is Not Security

Context: Private IP ranges or internal subnets are treated as trusted.

Problem: Address space does not establish trust.

Solution: Model subnet, security zone, access policy, identity, and exposure separately.

14.4 Pattern: Endpoint Exposure Trace

Context: A service is reachable from somewhere.

Problem: Teams cannot explain why exposure exists.

Solution:

ServiceEndpoint
  -> IPAddress / DNSRecord
  -> LoadBalancer / Ingress
  -> Route / SecurityGroup / FirewallRule
  -> NetworkPath
  -> Exposure
  -> SecurityFinding or AcceptedExposure

14.5 Pattern: Workload Flow to Policy

Context: Workloads need to communicate.

Problem: Policies are written without observed traffic or intended service relationships.

Solution:

ApplicationService dependency
  -> Intended NetworkFlow
  -> NetworkPolicy
  -> ObservedFlow
  -> ReachabilityTest
  -> Drift or Verification

14.6 Pattern: Management Plane Isolation

Context: Management interfaces are highly sensitive.

Problem: Management endpoints are accidentally reachable from broad scopes.

Solution: Mark ManagementEndpoint explicitly and apply stricter policy, access-control, monitoring, and exposure validation.

14.7 Pattern: Network Drift Reconciliation

Context: Declared configuration and observed network behavior diverge.

Problem: Teams cannot know whether the source of truth, controller, device, or observation is wrong.

Solution: Compare intended, declared, applied, and observed state and create ReconciliationResult with evidence and owner.

14.8 Pattern: Reachability as Evidence

Context: Compliance or security review requires proof that traffic is blocked or allowed.

Problem: Configuration alone is not enough evidence.

Solution: Use ReachabilityTest and ObservedFlow evidence to support allowed/denied claims.

14.9 Pattern: Zero Trust Overlay

Context: Network location is insufficient for security.

Problem: Teams rely on internal network segments for trust.

Solution: Combine NetworkPolicy, Access Control, identity, resource context, endpoint exposure, and continuous verification.

15. Network Profiles

15.1 Profile Format

A Network Profile SHALL declare:

id:
profile_name:
status:
implements:
  - InfoTechCanonNetworkModel
target_context:
included_concepts:
required_relationships:
required_metadata:
state_model:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:

15.2 Seed Profile: Small SaaS Network Profile

Purpose:

Provide a minimal network model for a small SaaS platform moving toward production readiness.

Included concepts:

NetworkDomain
NetworkZone
Subnet
Prefix
IPAddress
DNSRecord
Endpoint
PublicEndpoint
PrivateEndpoint
IngressEndpoint
EgressEndpoint
LoadBalancer
NetworkPolicy
SecurityGroup
RouteTable
Route
Exposure
ReachabilityClaim
ObservedFlow

Required relationships:

Endpoint assigned_to IPAddress
DNSRecord resolves_to Endpoint
Endpoint part_of NetworkZone
SecurityGroup permits NetworkFlow
SecurityGroup denies NetworkFlow
RouteTable routes_to NextHop
PublicEndpoint exposes Service
ReachabilityClaim evidenced_by ReachabilityTest

15.3 Seed Profile: NetBox Source-of-Truth Profile

Purpose:

Map NetBox-style IPAM/DCIM/source-of-truth concepts into InfoTechCanon Network.

Example mappings:

Site -> NetworkSite
Region -> NetworkRegion
Tenant -> NetworkTenant
Device -> NetworkDevice
Interface -> Interface
Cable -> Link / PhysicalLinkReference
Prefix -> Prefix
IPAddress -> IPAddress
VLAN -> VLAN / NetworkSegment
VRF -> VRF
Circuit -> Circuit
Provider Network -> ConnectivityService

Known deviations:

NetBox represents intended source-of-truth state, not necessarily observed runtime state.
NetBox does not directly enforce network behavior.
Observed flows and applied device state require additional sources.

15.4 Seed Profile: Kubernetes Network Profile

Purpose:

Represent Kubernetes networking concepts and policies.

Example mappings:

Cluster -> NetworkDomain / RuntimePlatformReference
Namespace -> NetworkZone / ResourceScope
Pod IP -> IPAddress
Service -> ServiceEndpoint
Ingress -> IngressEndpoint / PublicEndpoint or PrivateEndpoint
NetworkPolicy -> KubernetesNetworkPolicy
Pod selector -> EndpointSelector
Namespace selector -> ScopeSelector
Ingress rule -> AllowedFlow
Egress rule -> AllowedFlow

Known deviations:

Kubernetes NetworkPolicy support depends on the CNI provider.
A Kubernetes Service is not always equivalent to an external endpoint.
Pod IPs are often ephemeral.

15.5 Seed Profile: Cloud Network Profile

Purpose:

Represent cloud VPC/VNet networking across providers.

Included concepts:

NetworkDomain
VPCReference
VNetReference
Subnet
RouteTable
Route
SecurityGroup
NetworkACL
InternetGatewayReference
NAT
LoadBalancer
PrivateEndpoint
Peering
TransitGatewayReference
DNSZone
PublicEndpoint
Exposure

Mapping targets:

AWS VPC
Azure VNet
Google Cloud VPC
Cloudflare network services

15.6 Seed Profile: Service Mesh Network Profile

Purpose:

Represent service-to-service communication, mesh gateways, traffic policies, and mTLS-aware networking.

Included concepts:

ServiceMesh
Proxy
WorkloadEndpoint
ServiceEndpoint
TrafficPolicy
ServiceMeshPolicy
IngressGateway
EgressGateway
AllowedFlow
ObservedFlow
ReachabilityClaim

Mapping targets:

Istio
Linkerd
Consul Connect
Envoy
Gateway API

15.7 Seed Profile: Zero Trust Network Profile

Purpose:

Represent resource-centric network protection with identity, context, and continuous verification.

Included concepts:

ProtectedResourceReference
NetworkIntent
NetworkPolicy
Endpoint
Exposure
AccessControlReference
IdentityContextReference
DeviceContextReference
ReachabilityClaim
PolicyEnforcementPointReference

Required relationships:

NetworkIntent protects ProtectedResourceReference
AccessControlReference constrains Reachability
NetworkPolicy permits NetworkFlow
ReachabilityClaim evidenced_by TestOrObservation
Exposure assessed_by SecurityModel

15.8 Seed Profile: Network-as-Code Profile

Purpose:

Represent network configuration delivered through Git, IaC, controllers, and automation.

Included concepts:

NetworkConfiguration
DeclaredNetworkState
PipelineReference
ChangeRequestReference
AppliedNetworkState
Drift
ReconciliationResult
ValidationEvidence

Mapping targets:

Terraform
Ansible
Pulumi
Crossplane
Kubernetes manifests
vendor controllers

16. Mapping Model for the Network Standard

Mappings relate InfoTechCanon network concepts to external standards, tools, and products.

16.1 Mapping Types

Recommended mapping types:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent

16.2 Mapping Record

Example:

id: itc-map:network-topology-to-rfc8345
source_concept: itc-net:NetworkTopology
target_body: IETF RFC 8345
target_version: "2018"
target_concept: network / network-topology
mapping_type: closeMatch
scope:
  - generic topology modeling
not_valid_for:
  - all IPAM/DCIM inventory
  - all security policy semantics
rationale: >
  RFC 8345 provides a generic YANG topology model with networks, nodes,
  links, and termination points. InfoTechCanon extends the semantic context
  to include intent, policy, exposure, reachability, and source-of-truth boundaries.
confidence: high
status: candidate
owner: InfoTechCanonNetworkModel

16.3 Seed Mapping Targets

The Network Model SHOULD maintain mappings to:

YANG / RFC 7950
NMDA / RFC 8342
Network topology / RFC 8345
Intent-Based Networking / RFC 9315
NetBox IPAM/DCIM
Kubernetes NetworkPolicy
Kubernetes Gateway API
AWS VPC
Azure VNet
Google Cloud VPC
Cloudflare network services
Terraform provider network resources
Ansible network modules
Cisco NSO concepts
OpenConfig YANG models
BGP / routing model references
Istio / Envoy / service mesh concepts
NIST Zero Trust Architecture

17. Assimilation Hooks

The Network Model SHALL be able to receive new network standards, product models, cloud schemas, and operational practices through the InfoTechCanon assimilation process.

17.1 Assimilation Triggers

Assimilation may be triggered by:

new network source-of-truth tool
new cloud networking model
new network configuration standard
new firewall policy model
new service mesh model
new Kubernetes networking feature
new zero-trust network pattern
new network automation framework
new reachability analysis product
new recurring network classification conflict

17.2 Network Assimilation Output

A network assimilation SHOULD produce:

source summary
extracted network concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions

17.3 Recommended First Assimilation Candidates

NetBox data model
RFC 8345 network topology
RFC 8342 NMDA
RFC 9315 intent-based networking
Kubernetes NetworkPolicy
Kubernetes Gateway API
AWS VPC
Azure VNet
Google Cloud VPC
Istio traffic and authorization policy
OpenConfig YANG models
NIST SP 800-207 Zero Trust Architecture

18. Integration with Other InfoTechCanon Standards

18.1 Landscape Model

Network connects to Landscape through:

Environment
RuntimePlatform
Workload
Service
Endpoint
DataStore
DeploymentRecord
TechnicalService

18.2 Organization Model

Network imports organization concepts for:

network owner
network steward
operator
responsible team
approver
incident responder

18.3 Governance Model

Network imports governance concepts for:

network policy source
control objective
exception
evidence
review
approval
change decision

18.4 Task Model

Network creates or references tasks such as:

network change task
firewall review task
reachability investigation
drift remediation task
exposure remediation task
incident task

18.5 Tagging Standard

Network uses tags for:

environment
zone
segment
owner
exposure level
criticality
network domain
policy class

Tags must not replace network entities, policies, or relationships.

18.6 Access Control Model

Network imports access concepts for:

network administration permission
management endpoint access
zero-trust access decision
policy enforcement point

18.7 Security Model

Security imports network concepts for:

exposure
attack path
reachability
network segmentation
observed flow
management endpoint
public endpoint

18.8 Data Model

Data imports network concepts for:

data flow transport
data residency path
data egress
cross-border transfer evidence

18.9 DevSecOps Model

DevSecOps imports network concepts for:

network configuration as code
policy as code
network validation
deployment of network changes
drift detection

18.10 Observability Model

Observability should later import or map:

flow logs
packet telemetry
DNS logs
network metrics
reachability tests
latency
loss
error rate

19. Canon Interface Card Usage

Subsystems that implement or produce network knowledge SHOULD publish a Canon Interface Card.

Example:

subsystem: netbox-importer
implements:
  - InfoTechCanonNetworkModel
  - NetBoxSourceOfTruthProfile
produces:
  - NetworkSite
  - NetworkDevice
  - Interface
  - Prefix
  - IPAddress
  - VLAN
  - VRF
  - Circuit
consumes:
  - Team
  - Environment
relations:
  - IPAddress assigned_to Interface
  - Prefix part_of NetworkDomain
  - Interface connected_to Interface
source_of_truth:
  intended_ipam: NetBox
  intended_dci_inventory: NetBox
known_deviations:
  - does not represent observed flows
  - does not guarantee applied device configuration

20. Retrieval Requirements

The Network Model is designed for markdown-based infospaces.

20.1 Required Retrieval Properties

Every major concept SHOULD provide:

  • stable heading,
  • stable identifier,
  • short definition,
  • longer explanation,
  • examples,
  • distinction notes,
  • relationship examples,
  • mapping hooks,
  • profile references,
  • and common mistakes.

20.2 Agent Brief

A mature Network Model SHOULD include an agent-brief.md file with:

purpose
scope
owned concepts
imported concepts
core distinctions
do / do not rules
relationship patterns
minimal examples
common mistakes
profile list
mapping list

20.3 Indexes

The network information space SHOULD provide indexes by:

concept
relationship
network domain
addressing
topology
segment
policy
route
endpoint
flow
exposure
state context
profile
pattern
mapping target
status
source system

21. Conformance Levels

21.1 Reference-Conformant

A document or system is reference-conformant if it uses Network Model terminology consistently but does not implement structured metadata or validation rules.

21.2 Metadata-Conformant

A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.

21.3 Inventory-Conformant

A system is inventory-conformant if it represents network domains, sites, devices, interfaces, prefixes, IP addresses, and segments.

21.4 Topology-Conformant

A system is topology-conformant if it represents nodes, interfaces, links, paths, and termination points.

21.5 Policy-Conformant

A system is policy-conformant if it represents network policies, firewall rules, security groups, ACLs, or equivalent traffic-control constructs.

21.6 State-Conformant

A system is state-conformant if it distinguishes intended, declared, applied, observed, historical, and assessed network state.

21.7 Reachability-Conformant

A system is reachability-conformant if it represents reachability claims, tests, observed flows, allowed flows, denied flows, and evidence.

21.8 Profile-Conformant

A system is profile-conformant if it implements a declared Network Profile and passes its validation rules.

21.9 Assimilation-Conformant

A system or repository is assimilation-conformant if it can accept external network concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.

22. Validation Rules

Initial validation rules:

VAL-NET-001: NetworkIntent, NetworkPolicy, NetworkConfiguration, and ObservedNetworkState SHOULD be modeled as distinct concepts.

VAL-NET-002: Prefix, Subnet, VLAN, VRF, NetworkSegment, and SecurityZone SHOULD NOT be used interchangeably without a profile mapping.

VAL-NET-003: IPAddress SHOULD reference Prefix or allocation scope where available.

VAL-NET-004: DNSRecord SHOULD reference the endpoint, address, or service name it resolves to where available.

VAL-NET-005: Interface SHOULD reference its parent node or device.

VAL-NET-006: Link SHOULD connect termination points, interfaces, or nodes.

VAL-NET-007: Route SHOULD declare destination and next hop or action where available.

VAL-NET-008: NetworkPolicy SHOULD declare subject/source, destination, action, protocol/port/service, and direction where applicable.

VAL-NET-009: KubernetesNetworkPolicy SHOULD distinguish ingress and egress semantics.

VAL-NET-010: ReachabilityClaim SHOULD declare source, destination, protocol/service context, state context, and evidence where available.

VAL-NET-011: Exposure SHOULD declare source scope, target endpoint, and exposure type where available.

VAL-NET-012: PublicEndpoint SHOULD NOT imply unauthenticated access.

VAL-NET-013: PrivateEndpoint SHOULD NOT imply trusted access.

VAL-NET-014: ManagementEndpoint SHOULD be classified as sensitive unless explicitly justified otherwise.

VAL-NET-015: Network drift SHOULD identify which state views diverge.

VAL-NET-016: Source-of-truth assumptions SHOULD be explicit in every mature profile.

VAL-NET-017: Tags MUST NOT replace network policy, topology, addressing, or reachability relationships.

VAL-NET-018: Imported external network concepts SHOULD be represented through mapping records rather than silently reused.

VAL-NET-019: Profiles MUST NOT redefine canonical concepts. They may constrain them.

VAL-NET-020: Network security analysis SHOULD reference Security Model concepts rather than embedding full security semantics here.

23. Anti-Patterns

23.1 Subnet Equals Trust

Treating subnet membership as proof of trust.

23.2 Private Equals Safe

Assuming private endpoints are safe without access control, policy, monitoring, or context.

23.3 Policy Equals Intent

Using low-level rules as if they explain the desired outcome.

23.4 Configuration Equals Reality

Assuming declared configuration describes actual network behavior.

23.5 Topology Without State

Modeling links and devices without knowing intended, applied, or observed state.

23.6 Firewall Rule Graveyard

Accumulating rules without owner, purpose, evidence, review, or expiry.

23.7 Source-of-Truth Confusion

Letting NetBox, cloud APIs, devices, Git, and telemetry all claim authority over the same facts without boundaries.

23.8 Public Exposure by Accident

Publishing endpoints without explicit exposure classification or review.

23.9 Flow Logs Without Model

Collecting observed flows without linking them to services, policies, endpoints, and reachability claims.

23.10 Tool-Native Capture

Letting a cloud provider, firewall vendor, or Kubernetes CNI define the internal network model.

24. Initial Repository Placement

Recommended repository layout:

info-tech-canon/
  standards/
    network/
      InfoTechCanonNetworkModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

standards/network/InfoTechCanonNetworkModel.md
standards/network/agent-brief.md
standards/network/concepts/network-domain.md
standards/network/concepts/prefix.md
standards/network/concepts/ip-address.md
standards/network/concepts/network-segment.md
standards/network/concepts/endpoint.md
standards/network/concepts/network-policy.md
standards/network/concepts/network-intent.md
standards/network/concepts/reachability-claim.md
standards/network/concepts/exposure.md
standards/network/patterns/intent-policy-configuration-state-split.md
standards/network/patterns/source-of-truth-boundary.md
standards/network/patterns/endpoint-exposure-trace.md
standards/network/patterns/network-drift-reconciliation.md
standards/network/profiles/small-saas-network-profile.md
standards/network/profiles/netbox-source-of-truth-profile.md
standards/network/profiles/kubernetes-network-profile.md
standards/network/profiles/cloud-network-profile.md
standards/network/profiles/zero-trust-network-profile.md
standards/network/mappings/yang.yaml
standards/network/mappings/nmda.yaml
standards/network/mappings/rfc8345-topology.yaml
standards/network/mappings/netbox.yaml
standards/network/mappings/kubernetes-networkpolicy.yaml

25. Roadmap

Phase 1: Seed Stabilization

  • Establish this standard as InfoTechCanonNetworkModel.
  • Add seed concepts, relationship vocabulary, patterns, and profiles.
  • Define validation rules.
  • Align with Landscape, Security, Access Control, Governance, Data, DevSecOps, Task, and Tagging.

Phase 2: First Assimilations

Recommended first assimilations:

NetBox data model
RFC 7950 YANG
RFC 8342 NMDA
RFC 8345 network topology
RFC 9315 intent-based networking
Kubernetes NetworkPolicy
Kubernetes Gateway API
AWS VPC
Azure VNet
Google Cloud VPC
Istio / Envoy service mesh networking
NIST SP 800-207 Zero Trust Architecture

Phase 3: Profile Maturation

  • Mature Small SaaS Network Profile.
  • Mature NetBox Source-of-Truth Profile.
  • Mature Kubernetes Network Profile.
  • Mature Cloud Network Profile.
  • Mature Service Mesh Network Profile.
  • Mature Zero Trust Network Profile.
  • Mature Network-as-Code Profile.

Phase 4: Tooling Integration

  • Generate concept indexes.
  • Generate agent brief.
  • Create machine-readable YAML/JSON exports.
  • Add validation scripts.
  • Integrate NetBox, cloud APIs, Kubernetes APIs, network-policy repositories, flow logs, reachability tests, and security posture tools.

Phase 5: Network Intelligence Loop

  • Connect intended network state to declared configuration.
  • Connect declared configuration to applied state.
  • Connect applied state to observed flows.
  • Connect observed flows to reachability claims.
  • Connect exposure to security findings.
  • Connect drift to remediation tasks.
  • Connect policies to governance evidence.
  • Connect topology to landscape service dependencies.

26. Summary

The InfoTechCanon Network Model is the seed standard for representing network addressing, topology, connectivity, routing, policy, intent, reachability, exposure, segmentation, and state.

Its most important commitments are:

Separate addressing, topology, routing, policy, intent, configuration, state, flow, reachability, and exposure.

Treat intended, declared, applied, observed, historical, and assessed network state as distinct.

Support physical, virtual, cloud, Kubernetes, service-mesh, hybrid, and zero-trust network contexts.

Use source-of-truth boundaries to prevent tool conflicts.

Model reachability and exposure as first-class concepts.

Map to YANG, NMDA, IETF topology models, NetBox, Kubernetes NetworkPolicy, cloud networking,
service meshes, and Zero Trust without surrendering internal semantic autonomy.

Use profiles to make the model practical for SaaS systems, NetBox, Kubernetes, cloud networks,
service mesh, zero-trust design, and network-as-code workflows.

This makes the Network Model a core seed for production readiness, security posture, cloud-native architecture, reachability analysis, network automation, and interoperable infrastructure knowledge.

Reference in New Issue View Git Blame Copy Permalink