Received: from smtpout10.mo539.mail-out.ovh.net (smtpout10.mo539.mail-out.ovh.net [51.210.91.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 3DD7D31 for ; Wed, 23 Sep 2026 14:48:23 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=everything-ops.net header.s=ovhmo-selector-1 header.b=H4UKvbiO; dmarc=none; spf=pass (mx.ietf.org: domain of benoit@everything-ops.net designates 51.210.91.49 as permitted sender) smtp.mailfrom=benoit@everything-ops.net Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net [79.137.60.36]) by mo539.mail-out.ovh.net (Postfix) with ESMTPS id 4hqfwH5XWhz41wm for ; Wed, 23 Sep 2026 14:48:15 +0000 (UTC) Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net. [127.0.0.1]) by director2.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Wed, 23 Sep 2026 14:48:15 +0000 (UTC) Received: from mta11.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.54.162]) by director2.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hqfwH4Ppfz1yZQ for ; Wed, 23 Sep 2026 14:48:15 +0000 (UTC) Received: from everything-ops.net (unknown [10.1.6.11]) (Authenticated sender: benoit@everything-ops.net) by mta11.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTPSA id 419659A1C6B for ; Wed, 23 Sep 2026 14:48:15 +0000 (UTC) X-OVh-ClientIp: 91.86.233.52 Content-Type: multipart/alternative; boundary="------------ReSV4GL3t6WsWl433hCnn5SD" Message-ID: Date: Wed, 23 Sep 2026 16:48:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <179017450037.206572.12665151397228707075@dt-datatracker-69f6c78549-rwmtj> Content-Language: en-US, fr To: "green@ietf.org" From: "Benoit@everything-ops.net" In-Reply-To: <179017450037.206572.12665151397228707075@dt-datatracker-69f6c78549-rwmtj> X-Forwarded-Message-Id: <179017450037.206572.12665151397228707075@dt-datatracker-69f6c78549-rwmtj> x-ovh-tracer-id: 16622504753012057382 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: dmFkZTGYXBZwZDXBiufuC9Pmf8GbrWXKV9oAqELJCkcbsNU989kRsb6rx6jVDN0kXqghmg1ZteIlJETJTQwZbwPBsV1ms/9CeitsTf6YH1y68CY5JnRUaSZgCMdSTfhREyy3BrnUev8GPblNwpR+o1TmrbF3NYklhO/aShRTTdkZ7N051ZYv/KCkBX/oHPw0nGK/hO63d2gVxOlVNJOi/cvmTCKE5I6QBVE7K92KSOj5HL9ZvImoQKp/yHGNycUnDw5NWQLebhXmtp+6KSXxryv7kFgLDm19D1GpION2gd1ceQtNHZhMPokoRzgDNzluioHBhCjQvxb6K0gMLY8uNiZ+yZGsUfs7RTc6X8+W/oGwXkSplsGdqs1j64bJWMM3lp5asVmxUEwURyJmYBUFKZxhd6KDybBJcgAvaWPjey02XMih5hdg4iaPTeNWk/HpRHjxjC4hNOKAYVgVtHIFmvYgfAmohPTrHT0ElEFdGN8Q62QN1QX7Xa840fnpdJPfPS1uKAEXsP182DtZTJ5Hd9v+43XD80bBz2P0NhWEy+cMS6rKqjGJjPyFyBZx3kqHHOqOY/2H18fC3tBqtEdsjnAVZokxG6SopJwn4y3/DcJwDngkLRa7druQQ66DSzN8hxJidPCmLfgavPm9Oxt1ncZ5QK8xkZf3wuC1XO/5AC2Swuexsw DKIM-Signature: a=rsa-sha256; bh=mCDZ0qwGkKYuinCuSOM9zsCeFa5EcUdoip/VVCvMMJA=; c=relaxed/relaxed; d=everything-ops.net; h=From; s=ovhmo-selector-1; t=1790174895; v=1; b=H4UKvbiOlPFWEhuXQU73ud3M+i6J2xQJg3Vr3eUupzLJH0FwbEVEMi4NUJazQPrknpuJLoC3 gmLD4QEib10sCP0cxOrDxIfVLWK3kTkQ3JsZoEWmV2RZJiXSH6fdKtKGmTZ8fDAFcejS8ylh9Gh 0iCrnkLxyQJCaU4QsxOywB06CbN5lmyOY3eakxwnuGJtM/9pSdwotSHKO/02Z0cIl7NK2G64ji7 ZK8XhtyaKHYFiwnOjqq4wIiLoncHPR4lNs9IlPFsEHlDishssd5AXfwzrlo/3aK9FBqfYlMZTgf 4AeDSCBtHB0dTQKwbe13p7LGajn6lxzNfzBIn65Gna1uw== X-Spamd-Bar: / Message-ID-Hash: 2WD3LJRD2K75V33SXOK7Q7SO3ZWV6YAI X-Message-ID-Hash: 2WD3LJRD2K75V33SXOK7Q7SO3ZWV6YAI X-MailFrom: benoit@everything-ops.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Green] New Version Notification for draft-claise-green-capability-discovery-02.txt List-Id: Getting Ready for Energy-Efficient Networking WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------ReSV4GL3t6WsWl433hCnn5SD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a new version of the draft, which includes the feedback received from Qin and Marisol (thanks again). Changes since the previous version: Refined the Nameplate Power and max-power definitions (Terminology and the YANG module): both are rated continuous ceilings, not an expected operating value and not a transient or inrush peak, and max- power is the per-Power-State counterpart of Nameplate Power. Bumped the YANG module revision to 2026-09-22. Clarified that the RFC 9196 "node" is a data node, and that each per- node-capabilities entry is bound to one hardware Component through its node-selector. Extended the line card example to two Components, a line card and a fabric module, showing one per-node-capabilities entry per Component. Made explicit that a Component is "sleep-capable" (power-saving capable) when it advertises a low-power Power State, as a derived property rather than a separate capability flag. Noted that transition times are relative to power-state-on, and that direct transitions between two low-power states are not modeled. Stated explicitly in Operational Considerations that peak or inrush (transient) power and power-supply capabilities are not modeled, and that a power supply's own power is reported by the GREEN Power and Energy model. Added Operational Considerations guidance to compare max-exit-time against the applicable restoration or latency threshold, not only weigh Energy Saving, when selecting a low-power state. Regards, Benoit (on behalf of the authors) -------- Forwarded Message -------- Subject: New Version Notification for draft-claise-green-capability-discovery-02.txt Date: Wed, 23 Sep 2026 07:41:40 -0700 From: internet-drafts@ietf.org To: Benoit Claise , Gen Chen , Nils Warnke , Nils Warnke , Reshad Rahman A new version of Internet-Draft draft-claise-green-capability-discovery-02.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Name: draft-claise-green-capability-discovery Revision: 02 Title: A YANG Data Model for Power State Capability Discovery Date: 2026-09-23 Group: Individual Submission Pages: 28 URL: https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-02.txt Status: https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/ HTML: https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-02.html HTMLized: https://datatracker.ietf.org/doc/html/draft-claise-green-capability-discovery Diff: https://author-tools.ietf.org/iddiff?url2=draft-claise-green-capability-discovery-02 Abstract: This document defines a YANG data model that augments the system capabilities model of RFC 9196 to allow a network element to advertise, per hardware Component, the set of Power States that the Component supports, together with a static characterization of each such state: the expected and maximum Power the Component draws in it, and the time to enter and exit it. This capability model complements the operational Power and Energy data model defined in the GREEN Power and Energy YANG module, which reports the current Power State and the measured Power of a Component, but not which Power States are available, how much Power each draws, or how long transitions between them take. It is anchored to the hardware inventory of RFC 8348, reuses the Power State identities of the GREEN Power and Energy model, and, because it is static, may be provided at implementation time as YANG instance data per RFC 9195 so that an Energy Management System can learn a platform's Power State capabilities before the equipment is deployed or even powered on. The IETF Secretariat --------------ReSV4GL3t6WsWl433hCnn5SD Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

Here is a new version of the draft, which includes the feedback received from Qin and Marisol (thanks again).

Changes since the previous version:
   Refined the Nameplate Power and max-power definitions (Terminology
   and the YANG module): both are rated continuous ceilings, not an
   expected operating value and not a transient or inrush peak, and max-
   power is the per-Power-State counterpart of Nameplate Power.  Bumped
   the YANG module revision to 2026-09-22.

   Clarified that the RFC 9196 "node" is a data node, and that each per-
   node-capabilities entry is bound to one hardware Component through
   its node-selector.

   Extended the line card example to two Components, a line card and a
   fabric module, showing one per-node-capabilities entry per Component.

   Made explicit that a Component is "sleep-capable" (power-saving
   capable) when it advertises a low-power Power State, as a derived
   property rather than a separate capability flag.

   Noted that transition times are relative to power-state-on, and that
   direct transitions between two low-power states are not modeled.

   Stated explicitly in Operational Considerations that peak or inrush
   (transient) power and power-supply capabilities are not modeled, and
   that a power supply's own power is reported by the GREEN Power and
   Energy model.

   Added Operational Considerations guidance to compare max-exit-time
   against the applicable restoration or latency threshold, not only
   weigh Energy Saving, when selecting a low-power state.

Regards, Benoit (on behalf of the authors)


-------- Forwarded Message --------
Subject: New Version Notification for draft-claise-green-capability-discovery-02.txt
Date: Wed, 23 Sep 2026 07:41:40 -0700
From: internet-drafts@ietf.org
To: Benoit Claise <benoit@everything-ops.net>, Gen Chen <chengen@huawei.com>, Nils Warnke <Nils.Warnke@telekom.de>, Nils Warnke <nils.warnke@telekom.de>, Reshad Rahman <reshad@yahoo.com>


A new version of Internet-Draft draft-claise-green-capability-discovery-02.txt
has been successfully submitted by Benoit Claise and posted to the
IETF repository.

Name: draft-claise-green-capability-discovery
Revision: 02
Title: A YANG Data Model for Power State Capability Discovery
Date: 2026-09-23
Group: Individual Submission
Pages: 28
URL: https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-02.txt
Status: https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/
HTML: https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-02.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-claise-green-capability-discovery
Diff: https://author-tools.ietf.org/iddiff?url2=draft-claise-green-capability-discovery-02

Abstract:

This document defines a YANG data model that augments the system
capabilities model of RFC 9196 to allow a network element to
advertise, per hardware Component, the set of Power States that the
Component supports, together with a static characterization of each
such state: the expected and maximum Power the Component draws in it,
and the time to enter and exit it.

This capability model complements the operational Power and Energy
data model defined in the GREEN Power and Energy YANG module, which
reports the current Power State and the measured Power of a
Component, but not which Power States are available, how much Power
each draws, or how long transitions between them take. It is
anchored to the hardware inventory of RFC 8348, reuses the Power
State identities of the GREEN Power and Energy model, and, because it
is static, may be provided at implementation time as YANG instance
data per RFC 9195 so that an Energy Management System can learn a
platform's Power State capabilities before the equipment is deployed
or even powered on.



The IETF Secretariat


--------------ReSV4GL3t6WsWl433hCnn5SD--