A YANG Data Model for Factory Default Settings
Extracted elements (20)
Any cryptographic keys that are part of the factory-installed image (such as an IDevID certificate per BRSKI) are retained after factory-reset, while dynamically generated keys and certificates are deleted. This distinguishes between manufacturer-provisioned identity material and operator-provisioned configuration.
The 'factory-default' datastore is defined as optional (a device MAY implement factory-reset without it) because its sole purpose is to allow clients to programmatically discover the factory default configuration; the reset operation itself does not require the datastore to be exposed.
The contents of <factory-default> cannot be changed by management operations via NETCONF, RESTCONF, CLI, etc., unless specialized dedicated operations are provided. It can be read using standard NETCONF/RESTCONF protocol operations.
All data in any dynamic configuration datastores MUST be discarded when the factory-reset RPC is invoked.
If the 'factory-default' datastore is supported, it MUST be included in the list of datastores in the YANG library (RFC 8525).
Implementors SHOULD reboot the device and get it properly configured or otherwise restart processes needed to bootstrap it after a factory-reset RPC is executed.
The contents of <factory-default> are defined by the device vendor and MUST persist across device restarts.
The contents of the <operational> datastore MUST reflect the operational state of the device after applying the factory default configuration following a factory-reset.
The 'factory-default' datastore schema MUST be either (1) the same as the conventional configuration datastores or (2) a subset of the datastore schema for the conventional configuration datastores.
The 'factory-reset' RPC MUST restore nonvolatile storage to factory condition, which may entail deleting dynamically generated files such as keys, certificates, logs, and temporary files.
When factory-reset involves security-sensitive data such as cryptographic keys or passwords, it is RECOMMENDED to perform deletion as thoroughly as possible (e.g., overwriting storage with zeros and/or random bits) to reduce risk of sensitive material being recoverable.
A 'factory-default-datastore' feature is defined in the YANG module to indicate that the factory default configuration is available as a datastore, allowing conditional support for the feature.
The 'factory-default' datastore is an optional read-only datastore holding preset initial configuration used to initialize a server's configuration. A device MAY implement factory-reset without implementing this datastore, which only removes the ability to programmatically determine the factory default configuration.
The 'factory-reset' RPC resets all supported conventional read-write configuration datastores (<running>, <startup>, <candidate>) to the contents of <factory-default>, discards all dynamic configuration datastore data, and restores nonvolatile storage to factory condition.
The YANG module 'ietf-factory-default' defines the factory-reset RPC with nacm:default-deny-all access control, and a 'factory-default' identity (conditional on the factory-default-datastore feature) that bases on ds:datastore.
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-factory-default' in the 'ns' subregistry of the IETF XML Registry, and registered the YANG module 'ietf-factory-default' in the 'YANG Module Names' subregistry of the YANG Parameters registry.
Access to the 'factory-reset' RPC and the 'factory-default' datastore is considered sensitive and has been restricted using the 'default-deny-all' access control statement from RFC 8341 (NACM).
The 'factory-reset' RPC can prevent any further management of the device when the server is reset to factory default, for example if session and client configurations are included in the factory default contents or treated as dynamic files that are overwritten.
The mandatory-to-implement secure transport for NETCONF is SSH (RFC 6242), and for RESTCONF is TLS (RFC 8446). The YANG module is designed to be accessed via these protocols.
The owner of the device MUST NOT rely on any sensitive data (e.g., private keys) being forensically unrecoverable from the device's nonvolatile storage after a 'factory-reset' RPC has been invoked, as there is no guarantee data is wiped to any particular data-cleansing standard.