Getting Ready for Energy-Efficient Networking M. Palmero Internet-Draft Independent Intended status: Standards Track D. Lopez Expires: 6 May 2027 A. Mendez Perez Telefonica P. Andersson Ionio Systems R. Osterberg Kodeta 2 November 2026 Provenance Traceability for the GREEN Controller YANG Model draft-madpr-green-provenance-01 Abstract This document defines a YANG module that augments the GREEN network controller YANG model [GreenController] to record the result of provenance verification for each Energy Object. The augmentation builds on the COSE-based signing mechanism defined in [ProvenanceDraft]. The controller verifies each signature it receives against a key it trusts. For each node or component, it records whether the most recent signature was valid, which key was used to sign it, and who is responsible for that key: the device itself, the network controller acting on its behalf, or an external authority such as a grid energy provider. A signature that cannot be verified, for example because the key is unknown or the signature is missing, is recorded as a failure, with the reason. This allows operators and auditors to check not just that energy data is correct, but where it came from, and how much trust applies to each source. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://marisolpalmero.github.io/green-provenance/draft-madpr-green- provenance.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-madpr-green-provenance/. Discussion of this document takes place on the Getting Ready for Energy-Efficient Networking Working Group mailing list (mailto:green@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/green/. Subscribe at https://www.ietf.org/mailman/listinfo/green/. Source for this draft and an issue tracker can be found at https://github.com/marisolpalmero/green-provenance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Motivating Scenarios 2. Terminology 3. Design Rationale 3.1. Why Augment the Controller Model 3.2. Why a Grouping Used at Node and Component Level 3.3. Why the Provenance Signature Itself Is Not Stored 3.4. Why provenance-key-owner and provenance-key-id are both needed 3.5. Relationship to provenance-key-id and the underlying COSE kid 4. YANG Module 4.1. Tree Diagram 4.2. YANG Module Definition 5. Operational Considerations 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Authors' Addresses 1. Introduction The GREEN controller YANG model [GreenController] lets a network controller describe the energy and power setup of a network: which nodes and components exist, how energy and power data is collected for them, and how that data relates to the controller's inventory. Operators and auditors use this information for regulatory reporting, renewable energy attribution and carbon accounting. They need to know not only what the data says, but where it came from and whether it can be trusted. [ProvenanceDraft] defines how to attest YANG data with COSE signatures [RFC9052]. A provenance-signature can accompany YANG instance data, NETCONF notifications, or YANG-Push updates, so that a receiver can verify integrity and origin. It leaves the meaning of the COSE Key Identifier (kid) to the signer and the verifier: it is "to be locally agreed, used and interpreted by the signer and the signature validator" ([ProvenanceDraft], Section 3.1). That document says how to sign and verify. It does not say how the result of verification is kept in a management data model. The three documents fit together as follows: * [ProvenanceDraft] (OPSAWG) defines how data is signed and verified. * [GreenController] defines what energy data a controller collects, from which nodes and components, and how that collection is described. * This document defines the verification outcome for an Energy Object, or external data, like source of energy, that the controller will need and who owns the signing key. It does not change how signing or verification works, and it does not change how collection is described. This document augments the energy node attributes of [GreenController] with five read-only leaves, defined once in a grouping and used at two levels, the node and the component. The leaves expose: 1. the Key Identifier (kid) associated with the most recently verified/received provenance signature; 2. the entity that provisioned and manages the corresponding signing key; 3. whether verification of the most recently received provenance signature succeeded; 4. the time at which provenance verification most recently succeeded; and 5. the reason for the most recent verification failure, when applicable. These leaves are controller-side operational state. They exist only in the controller's datastore, and they are not carried in YANG-Push notifications, NETCONF replies, or other messages sent by devices. Only the outcome of verification is stored. The provenance-signature defined by [ProvenanceDraft] is not stored in the datastore. It is carried in the transport or notification that delivers the data, and the controller verifies it on receipt. The controller model describes what is collected, and this draft say whether the collected data is verified. Together they can support the "Read provenance data" step of [GreenController], where a consumer follows the collection graph, compares it with the inventory, and checks for unreported devices or double counting. 1.1. Motivating Scenarios The augmentation supports three deployment scenarios: * Energy Object signs its own telemetry. * Controller signs on behalf of the Energy Object. * External authority signs externally supplied information. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the term "Energy Object" as defined in [GreenTerminology]. This document uses the term "kid" (Key Identifier) as defined in [RFC9052], Section 3.1, and as further qualified in [ProvenanceDraft], Section 3.1. 3. Design Rationale 3.1. Why Augment the Controller Model Provenance state describes how much trust applies to a piece of energy-related data. It is metadata about that data, not a separate object. For that reason this document augments the energy node attributes of [GreenController], at the Energy Object levels, instead of defining a parallel tree. Data supplied by an external authority, such as a grid operator, is expected to be represented in the controller as an Energy Object, so that the same leaves apply. An earlier version of this idea targeted the per-device energy- objects tree of [PowerAndEnergy]. The signature is verified by the controller, and the controller's own model is where the trust decision belongs. A controller that reads many devices, and also reads legacy devices through other means, has one place to look. An earlier target also did not suit the case of a controller that signs for a device that cannot sign. The leaves are config false, so they are operational state. Under the Network Management Datastore Architecture [RFC8342], they are read from the operational datastore of the controller and are never configured. The controller derives their values from its own verification procedure and updates the operational state as telemetry arrives. This document does not require any change to device-side YANG. A device that signs its own telemetry produces the COSE signature as described in [ProvenanceDraft], and the leaves in this document live on the controller. The controller verifies the data as it was received. It cannot tell by itself whether the device was in a trustworthy state when it produced the data. Evidence about the device itself, for example hardware-rooted attestation of its signing key, is outside the scope of this document. An Energy Object MUST NOT populate these leaves, and a controller MUST NOT accept values for them from an Energy Object. 3.2. Why a Grouping Used at Node and Component Level Some signers cover a whole node, for example a router that signs everything it reports. Others cover one component, for example a power supply measured by an external meter whose key is held by the controller. The same five leaves apply in both cases, so they are defined in one grouping and augmented at both levels. A deployment can fill in whichever level matches how signing is done, and leave the other empty. 3.3. Why the Provenance Signature Itself Is Not Stored An early YANG Doctors review of [ProvenanceDraft] raised a specific interoperability concern: two YANG datastore implementations that are independently compliant with [RFC7950] MAY serialize a set of augmented leaves in different element orders, particularly when more than one module augments the same parent. Where signature verification depends on re-canonicalizing a complete YANG-level serialization, this divergence can prevent successful cross- implementation verification, even though the underlying content is semantically identical. This document avoids that problem entirely. The provenance-signature binary defined in [ProvenanceDraft] is never written into the energy- objects operational tree. It is carried only in the transport-level envelope, as a YANG-Push notification, as a NETCONF RPC reply, or as an instance-data document; in which it was received, and is verified upon receipt by the controller at the point of receipt. This document records only the verification result, not the signature itself, so the interoperability concern above does not apply. 3.4. Why provenance-key-owner and provenance-key-id are both needed A successful provenance verification identifies the signing key used to produce the signature. It does not identify the entity that manages that key. The GREEN Framework [GreenFramework] distinguishes between device- initiated and controller-initiated, with provenance generation: * In the device-initiated model, the Energy Object generates and manages its own signing key, produces the provenance signature, and sends it with the telemetry. The controller verifies the signature and then sets provenance-key-owner to key-owner-device in its own datastore. The Energy Object has no knowledge of the leaf and does not set it. * In the controller-initiated model, the controller generates the provenance signature on behalf of an Energy Object that does not provide provenance information itself, and sets provenance-key- owner to key-owner-controller. Both models produce a valid COSE signature that can be verified using the associated kid, but they represent different trust relationships. This document defines the provenance-key-owner leaf to expose that trust relationship explicitly. Rather than requiring management applications to infer implementation-specific semantics from the kid, the controller exposes the entity that manages the signing key associated with the verified signature. When provenance-key-owner is key-owner-device, the verified signature was generated using a key managed by the Energy Object, corresponding to the device-initiated provenance model. When provenance-key-owner is key-owner-controller, the verified signature was generated using a key managed by the controller on behalf of the Energy Object, corresponding to the controller-initiated provenance model. The key- owner-external-ca identity extends this model to cover telemetry or energy-related information whose provenance is established by an authority outside the operator's administrative domain, such as a grid energy provider. Representing the provenance model explicitly as operational state allows controllers, management applications, and auditors to determine the applicable trust relationship without interpreting implementation-specific kid values. This also provides a consistent, machine-readable representation across implementations that may use different conventions for assigning kid values. Additional deployment models MAY define identities derived from key- owner-type without requiring changes to the module. 3.5. Relationship to provenance-key-id and the underlying COSE kid The provenance-key-id leaf does not define a new identifier. Rather, it exposes the kid value carried in the protected header of the COSE_Sign1 structure defined in [ProvenanceDraft] as operational state. The kid identifies the signing key used to produce a signature; it does not identify the Energy Object itself. Unlike a device identifier such as a UUID, which remains stable across key rotations and device restarts, a kid may change whenever the corresponding signing key is replaced. As specified by [RFC9052], the format and semantics of the kid are application-defined and it is not required to be globally unique. In deployments where an Energy Object manages its own signing key, the kid is chosen by the Energy Object. One suitable representation is a COSE Key Thumbprint URI as specified in RFC 9679, allowing the controller to verify the kid independently using the registered public key associated with the Energy Object. In deployments where the controller signs telemetry on behalf of an Energy Object, the controller assigns the kid according to its own administrative namespace. The controller SHOULD maintain a local mapping between the assigned kid value and the corresponding Energy Object identifier. 4. YANG Module 4.1. Tree Diagram The following tree diagram, using the syntax defined in [RFC8340], illustrates the augmentation defined by this document. module: ietf-green-provenance augment /nw:networks/nw:network/nw:node /pen:energy-node-attributes: +--ro provenance-key-id? string +--ro provenance-key-owner? identityref +--ro traceability-verified? boolean +--ro traceability-last-verified? yang:date-and-time +--ro traceability-failure-reason? string augment /nw:networks/nw:network/nw:node /pen:energy-node-attributes/pen:component: +--ro provenance-key-id? string +--ro provenance-key-owner? identityref +--ro traceability-verified? boolean +--ro traceability-last-verified? yang:date-and-time +--ro traceability-failure-reason? string The same five leaves are added at node and component level through the grouping provenance-state. 4.2. YANG Module Definition ~~~ yang file "ietf-green-provenance@2026-10-28.yang" module ietf-green-provenance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-green-provenance"; prefix igp; import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-power-energy-network { prefix pen; reference "I-D.swepcarl-green-controller-yang: A YANG Data Model for GREEN Network Controllers"; } import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types"; } organization "IETF GREEN Working Group"; contact "WG Web: WG List: "; description "This module augments the GREEN controller YANG model (ietf-power-energy-network) with provenance traceability leaves for each energy node and component, exposing the outcome of COSE signature verification performed by the controller. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-10-28 { description "Initial revision."; reference "RFC XXXX: Provenance Traceability Augmentation for the GREEN Controller YANG Model"; } /* Identities */ identity key-owner-type { description "Base identity for the entity that provisioned and manages the COSE signing key used to sign data associated with an Energy Object."; } identity key-owner-device { base key-owner-type; description "The Energy Object generated and manages its own key pair and self-attests its own telemetry. The controller records this value after verifying the signature; the Energy Object does not set it."; } identity key-owner-controller { base key-owner-type; description "The controller generated and manages the key pair on behalf of the Energy Object, typically because the Energy Object lacks native signing capability. The controller signs data it collected on the Energy Object's behalf."; } identity key-owner-external-ca { base key-owner-type; description "The key belongs to a certificate authority or data authority outside the operator's administrative domain, such as a grid energy provider or carbon intensity service."; } /* Grouping */ grouping provenance-state { description "Provenance traceability state. All leaves are set by the controller after verifying a COSE provenance signature associated with the node or component, per I-D.ietf-opsawg-yang-provenance. The provenance-signature value itself is not stored here; see Section 3.2 of this document."; leaf provenance-key-id { type string { length "1..256"; } config false; description "The Key Identifier (kid) from the COSE_Sign1 protected header of the most recently verified provenance signature associated with this node or component. Absent if no provenance signature has been received and verified."; reference "RFC 9052: CBOR Object Signing and Encryption (COSE), Section 3.1; I-D.ietf-opsawg-yang-provenance, Section 3.1"; } leaf provenance-key-owner { type identityref { base key-owner-type; } config false; description "Identifies the entity that provisioned and manages the signing key whose kid is recorded in provenance-key-id. Absent if no provenance signature has been received and verified."; } leaf traceability-verified { type boolean; config false; description "Whether the most recently received provenance signature for this node or component passed COSE verification. A controller SHOULD NOT use its data in any reporting or control pipeline while this leaf is false. Absent if no verification has been attempted."; } leaf traceability-last-verified { type yang:date-and-time; config false; description "The date and time at which the controller last successfully verified a provenance signature for this node or component. Absent if no successful verification has occurred."; } leaf traceability-failure-reason { when "../traceability-verified = 'false'"; type string { length "0..512"; } config false; description "A human-readable explanation of the most recent provenance verification failure. Present only when traceability-verified is false."; } } /* Augmentations */ augment "/nw:networks/nw:network/nw:node" + "/pen:energy-node-attributes" { description "Adds provenance state at node level."; uses provenance-state; } augment "/nw:networks/nw:network/nw:node" + "/pen:energy-node-attributes/pen:component" { description "Adds provenance state at component level."; uses provenance-state; } } 5. Operational Considerations This document defines two implementation roles. A device (Energy Object) that signs its own telemetry implements [ProvenanceDraft]. It holds a signing key, preferably in hardware, signs the data it reports, and carries the signature in the notification that delivers the data. It does not implement the module defined in this document, it does not see the leaves defined here, and no YANG change is needed on the device. A controller implements the module defined in this document. A controller SHOULD verify every signature it receives against a key it trusts. For a device that cannot sign, for example one that is read over SNMP, the controller can collect the data, sign it on the device's behalf, and record key-owner-controller as provenance-key-owner. Auditors can then tell this apart from a device that signed for itself. This document does not mandate a verification interval. A controller MAY verify on every received update, or at a configured polling interval, as appropriate to the deployment. The leaves are only meaningful where the controller has created energy-node-attributes for the node or component, as described in [GreenController]. Where signing covers a whole node, the controller fills the node-level leaves. Where signing covers one component, it fills the component-level leaves. A controller MAY fill both. The identifier of the node is chosen by the controller. The identity of the underlying device is held in the references of [GreenController]. The provenance-key-id is not a substitute for either, and a consumer that wants to relate a signature to a device follows the references, then the kid. When traceability-verified is false, this document RECOMMENDS that a controller exclude the associated node or component's data from any energy accounting, carbon reporting, or automated control decision until a subsequent verification succeeds. 6. Security Considerations Implementations MUST ensure that the traceability-verified and related leaves defined in this document cannot be set directly via configuration, and are exclusively derived from an actual COSE verification procedure performed by the controller. As these leaves are config false, conformant implementations already enforce this at the data model level. Implementers are nonetheless reminded that the integrity of these leaves depends on the correctness of the verification procedure that populates them. Access control mechanisms such as NACM [RFC8341] SHOULD restrict write access to the underlying datastore state. The key-owner-external-ca identity introduces a dependency on a trust anchor for the external authority in question. This document does not define a mechanism for provisioning or rotating such trust anchors; this is left to deployment-specific or future specification. A valid signature shows that the data was not changed after it was signed and that it was signed with a given key. It does not show that the device was in a good state when it produced the data, or that the signing key is protected on the device. Remote attestation of the device, for example as described in the RATS architecture [RFC9334], can give that assurance and is complementary to this document. Work on hardware-rooted attestation, such as [I-D.ramki-ptp-hardware-rooted-attestation], which applies it to time synchronization, may be relevant for protecting signing keys. Work on a normalized representation of YANG data, such as [I-D.mendez-opsawg-yang-normalization], may help signer and verifier agree on the bytes that are signed. 7. IANA Considerations This document registers one URI in the "ns" subregistry of the IETF XML Registry [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-green-provenance Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers one YANG module in the "YANG Module Names" registry [RFC6020]: name: ietf-green-provenance namespace: urn:ietf:params:xml:ns:yang:ietf-green-provenance prefix: igp reference: RFC XXXX 8. References 8.1. Normative References [GreenController] Lindblad, J., "A YANG Data Model for GREEN Network Controllers", Work in Progress, Internet-Draft, draft- swepcarl-green-controller-yang-00, n.d., . [ProvenanceDraft] Lopez, D., Pastor, A., Feng, A. H., Perez, A. M., and H. Birkholz, "Applying COSE Signatures for YANG Data Provenance", Work in Progress, Internet-Draft, draft-ietf- opsawg-yang-provenance-06, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . 8.2. Informative References [GreenFramework] Claise, B., Contreras, L. M., Lindblad, J., Palmero, M. P., Stephan, E., and Q. Wu, "Framework for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-ietf-green-framework-02, 5 July 2026, . [GreenTerminology] Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M. P. Palmero, "Terminology for Energy Efficiency Network Management", Work in Progress, Internet-Draft, draft-ietf- green-terminology-03, 30 October 2026, . [I-D.mendez-opsawg-yang-normalization] Perez, A. M. and D. Lopez, "Normalized Representation of YANG Data for Equivalence Evaluation", Work in Progress, Internet-Draft, draft-mendez-opsawg-yang-normalization-00, 22 October 2026, . [I-D.ramki-ptp-hardware-rooted-attestation] Krishnan, R., Richardson, M., Lopez, D., Prasad, A., and S. Addepalli, "Hardware-Rooted Attestation for Precision Time Protocol: Scalable Workload Identity and Phased PQC Readiness", Work in Progress, Internet-Draft, draft-ramki- ptp-hardware-rooted-attestation-02, 18 October 2026, . [PowerAndEnergy] Claise, B., Chen, G., Palmero, M. P., and J. Lindblad, "Power and Energy YANG Module", Work in Progress, Internet-Draft, draft-ietf-green-power-and-energy-yang-05, 2 November 2026, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Acknowledgments The authors would like to thank the participants of the GREEN Working Group design team and the IETF Hackathon sessions where the underlying COSE provenance mechanism was implemented and tested against the scenarios that motivated this document. The authors would also like to thank Jan Lindblad for his YANG Doctors review of [ProvenanceDraft], which directly informed the design rationale in Section 3 regarding the placement of the provenance signature outside the augmented datastore tree. Authors' Addresses Marisol Palmero Independent Email: marisol.ietf@gmail.com Diego Lopez Telefonica Email: diego.r.lopez@telefonica.com Ana Mendez Perez Telefonica Email: ana.mendezperez@telefonica.com Per Andersson Ionio Systems Email: per.ietf@ionio.se Robin Osterberg Kodeta Email: robin.ietf@kodeta.se