Marisol,
Look for these changes in the next version of draft-many-teas-power-steering
and draft-many-lsr-power-groups.
I will probably have to contact you for coaching as I make the changes.
Ron
________________________________
From: Marisol <[email protected]>
Sent: Thursday, August 20, 2026 9:47 AM
To: Bonica, Ron <[email protected]>
Cc: Vishnu Pavan Beeram <[email protected]>; Gunter van de Velde
(Nokia) <[email protected]>; Acee Lindem <[email protected]>;
TEAS WG Chairs <[email protected]>; Tony Li <[email protected]>;
Christian Hopps <[email protected]>; “[email protected]” <[email protected]>; Les
Ginsberg <[email protected]>; lsr-chairs <[email protected]>; lsr
<[email protected]>; Getting Ready for Energy-Efficient Networking Discussion List
<[email protected]>
Subject: Re: [Lsr] Re: Adoption of draft-many-lsr-power-group
Hi Ron,
Under the Terminology section, there's a reference to
draft-many-teas-power-steering. I checked that draft as well, and it doesn't
reference the GREEN work either.
* Under Terminology, I'd suggest reviewing and referencing, possibly as an
extension: draft-ietf-green-terminology.
I'd also review the GREEN use cases to make sure your use case(s) are covered
under: draft-ietf-green-use-cases. And noted in the Introduction section,
similar to your reference to [I-D.many-teas-power-steering]
In the Operational section, I'd include the requirements for the GREEN
framework, or any other framework that might support the use case, ... also
including the device-specific details, that to my understanding should be align
with the GREEN YANG data model:
* draft-ietf-green-framework —> see the relationship defined in Section
4.3: "A Functional Dependency Relationship is a relationship where one Energy
Object requires another Energy Object to be in an operational state for its own
correct functioning..."
* draft-ietf-green-power-and-energy-yang, where the relationship YANG data
model has been included.
I'd reference these in Section 2 (Terminology) and/or Section 3, where relevant
terms/dependencies are introduced.
Point 3 is covered with your suggestion. Please keep in mind that under the
GREEN YANG data model
Just for you to note:
GREEN WG is considering accuracy and units for power in watts.
leaf data-source-accuracy {
type identityref {
base data-source-accuracy;
}
default accuracy-like-parent;
description
"The accuracy of the power data source. Indicates whether
the data source is a direct measurement, an estimate, or
unavailable and also the accuracy level of the data source.
By default, the accuracy is inherited from the parent energy
object, facilitating hierarchical accuracy definitions
without the need to specify accuracy at every level.
This metadata is crucial for network management
applications to assess the reliability and accuracy of the
power data.";
}
hth,
Marisol
On Wed, Aug 19, 2026 at 3:58 PM Bonica, Ron
<[email protected]<mailto:[email protected]>> wrote:
>
> Hello Marisol,
>
> Thanks for your review.
>
> Regarding points 1 and 2, if you could send me the appropriate references, I
> would be glad to add them. Also, it would be helpful if you could suggest
> where in the document these references should be made.
>
> Regarding point 3, would your concern be addressed if we added a Management
> Considerations Section that said:
>
> Data items described in this document SHOULD be consistent with
> device-reported power data available via the GREEN YANG model where such data
> is available, to establish a baseline for interoperability between the
> IGP-distributed value and the management-plane value.
>
>
> Maybe this would be the place to reference the Green documents?
>
> Ron
>
> ________________________________
> From: Marisol <[email protected]<mailto:[email protected]>>
> Sent: Wednesday, August 19, 2026 6:28 AM
> To: Vishnu Pavan Beeram
> <[email protected]<mailto:[email protected]>>
> Cc: Gunter van de Velde (Nokia)
> <[email protected]<mailto:[email protected]>>; Acee
> Lindem <[email protected]<mailto:[email protected]>>; TEAS WG Chairs
> <[email protected]<mailto:[email protected]>>; Tony Li
> <[email protected]<mailto:[email protected]>>; Christian Hopps
> <[email protected]<mailto:[email protected]>>;
> “[email protected]<mailto:[email protected]>”
> <[email protected]<mailto:[email protected]>>; Les Ginsberg
> <[email protected]<mailto:[email protected]>>; lsr-chairs
> <[email protected]<mailto:[email protected]>>; lsr
> <[email protected]<mailto:[email protected]>>; Getting Ready for Energy-Efficient
> Networking Discussion List <[email protected]<mailto:[email protected]>>
> Subject: [Lsr] Re: Adoption of draft-many-lsr-power-group
>
>
> As this draft, draft-many-lsr-power-group, is related to what we are working
> on the GREEN WG, I would like to highlight some points that will require some
> kind of discussion/references, to my understanding, before the work gets
> adopted:
>
>
> 1. Informative cross-reference to GREEN WG related work:
>
> The draft currently carries no reference to any GREEN WG document. The Power
> Group concept, Sleep Status, and PSP metric all directly relate to the energy
> management model defined in the GREEN framework (draft-ietf-green-framework)
> and GREEN YANG data model (draft-ietf-green-power-and-energy-yang). We
> request to address: that Power Group membership and PSP values are intended
> to be consistent with what a device reports via the GREEN YANG model at the
> management plane.
>
> 2. Power Group parent-child dependency maps to the GREEN YANG Functional
> Enablement Relationship
>
> draft-many-lsr-power-group defines: "One Power Group is the child of another
> if any one of the child components depends upon any one of the parent
> components." This is precisely the Functional Enablement Relationship that
> GREEN WG has extended in its YANG model via the 'enabled-by' and 'enabling'
> identity pair. The draft should acknowledge this mapping explicitly, so that
> implementations can correlate IS-IS-advertised Power Group hierarchy with the
> management-plane relationship model in GREEN YANG without ambiguity.
>
> 3. PSP (Power Savings Potential) is a gap in the GREEN YANG model
>
> The PSP field (power saveable in milliwatts if a Power Group goes to sleep)
> is a prospective metric with no equivalent in the current GREEN YANG data
> model, which defines only actual and historical power values. Before the
> draft is adopted, it should be considered a prospective power metric leaf in
> a future revision of the YANG model. We request that the LSR document note
> that PSP values SHOULD be consistent with device-reported power data
> available via the GREEN YANG model where such data is available, to establish
> a baseline for interoperability between the IGP-distributed value and the
> management-plane value. It will be good to address this requirement from the
> LSR authors.
>
> From my point of view, the three points above are requests for alignment
> before the work is adopted.
>
>
> The guidance that we are getting/adopting by the GREEN WG is to first focus
> and prioritize the device level energy capabilities, monitoring and settings,
> to later address other use cases, including collector part, routing
> capabilities, etc.
>
> Note: adding the GREEN WG to the thread
>
>
> thanks,
>
> Marisol
>
>
>
> On Tue, Aug 18, 2026 at 1:13 PM Vishnu Pavan Beeram
> <[email protected]<mailto:[email protected]>> wrote:
>
> Gunter,
>
> Since I am a co-author of these drafts, I've recused myself from initiating
> the adoption process. Oscar is currently on vacation (as are many folks in
> Europe) and my understanding is that he will initiate the process once he
> returns toward the end of this month.
>
> Regards,
> Pavan
>
> On Tue, Aug 18, 2026 at 12:41 AM Gunter van de Velde (Nokia)
> <[email protected]<mailto:[email protected]>> wrote:
>
> +teas-chairs
>
> Hi Italo, Carlos & Vishnupavan,
>
> Can you help understand lsr-chairs and authors of draft-many-lsr-power-group
> when the TEAS WG plans to start an adoption call for the companion draft -
> https://datatracker.ietf.org/doc/draft-many-teas-power-steering/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOk1XDNW_o$>
>
> Many thanks,
> G/
>
> ________________________________
> From: Acee Lindem <[email protected]<mailto:[email protected]>>
> Sent: Monday, August 17, 2026 9:34 PM
> To: Gunter van de Velde (Nokia)
> <[email protected]<mailto:[email protected]>>
> Cc: Tony Li <[email protected]<mailto:[email protected]>>; Christian
> Hopps <[email protected]<mailto:[email protected]>>;
> "“[email protected]<mailto:[email protected]>”"
> <[email protected]<mailto:[email protected]>>; Les Ginsberg
> <[email protected]<mailto:[email protected]>>; lsr-chairs
> <[email protected]<mailto:[email protected]>>; lsr
> <[email protected]<mailto:[email protected]>>
> Subject: Re: [Lsr] Adoption of draft-many-lsr-power-group
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL
> nok.it/ext<https://urldefense.com/v3/__http://nok.it/ext__;!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOk8vEl2iQ$>
> for additional information.
>
>
>
> Speaking as WG Co-chair:
>
> Gunter - given the amount of discussion the draft had generated, I don't see
> that there has been any undo delay in the adoption call.
>
> One thing you could follow up on is when the TEAS WG plans to start an
> adoption call for the companion draft -
> https://datatracker.ietf.org/doc/draft-many-teas-power-steering/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOk1XDNW_o$>
>
> I haven't seen it yet (although I get lots of Email).
>
> Thanks,
> Acee
>
> > On Aug 17, 2026, at 4:41 AM, Gunter van de Velde (Nokia)
> > <[email protected]<mailto:[email protected]>> wrote:
> >
> > Hi Tony, All,
> >
> > Message received.
> > I observed that Chris requested a WG adoption call for
> > draft-many-lsr-power-group few hours ago.
> >
> > I believe we should, as Chris proposed, give the normal route a chance. If
> > that doesn’t work, we can unpack the situation together and converge on the
> > next steps.
> >
> > G/
> >
> >
> >
> >
> >
> > From: Tony Li <[email protected]<mailto:[email protected]>>
> > Sent: Friday, August 14, 2026 8:12 PM
> > To: Christian Hopps <[email protected]<mailto:[email protected]>>;
> > "“[email protected]<mailto:[email protected]>”"
> > <[email protected]<mailto:[email protected]>>
> > Cc: Les Ginsberg <[email protected]<mailto:[email protected]>>;
> > lsr-chairs <[email protected]<mailto:[email protected]>>; lsr
> > <[email protected]<mailto:[email protected]>>
> > Subject: Re: [Lsr] Adoption of draft-many-lsr-power-group
> > CAUTION: This is an external email. Please be very careful when clicking
> > links or opening attachments. See the URL
> > nok.it/ext<https://urldefense.com/v3/__http://nok.it/ext__;!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOk8vEl2iQ$>
> > for additional information.
> >
> >
> > Hi,
> > We still seem stuck. Could I get some AD help, please?
> >
> > Thanks,
> > Tony
> >
> >
> > On Aug 7, 2026, at 8:53 AM, Tony Li
> > <[email protected]<mailto:[email protected]>> wrote:
> >
> > Hi,
> > It's now two weeks after the meeting. Could the chairs please proceed?
> >
> > Thanks,
> > Tony
> >
> >
> > On Mon, Jul 20, 2026 at 2:30 PM Christian Hopps
> > <[email protected]<mailto:[email protected]>> wrote:
> > Can we please pause this discussion until after the meeting? I don’t think
> > anything helpful is going on here that benefits the document or the WG.
> >
> > No one is raising bars on whims and no one is end running.
> >
> > Thanks,
> > Chris.
> >
> >
> > On Jul 20, 2026, at 22:47, Les Ginsberg (ginsberg)
> > <[email protected]<mailto:[email protected]>> wrote:
> >
> > Tony –
> >
> > I think Chris and I have expressed the same point.
> > I also think you seem to want to “pick a fight” – and I am not interested
> > in that.
> >
> > I will call your attention to the following from RFC 7120. Although RFC
> > 7120 is not directly applicable in this case, it is related and the concern
> > expressed there seems very relevant to this case.
> >
> > From
> > https://www.rfc-editor.org/rfc/rfc7120.html#section-5<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7120.html*section-5__;Iw!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOkSsw0QtY$>
> >
> > “There is a significant concern that the procedures in this document
> >
> > could be used as an end-run on the IETF process to achieve code point
> > allocation when an RFC will not be published. For example, a WG or a
> > WG chair might be pressured to obtain an early allocation for a
> > protocol extension for a particular company or for another Standards
> > Development Organization even though it might be predicted that an
> > IETF LC or IESG Evaluation would reject the approach that is
> > documented.”
> >
> > Les
> >
> >
> > From: Tony Li <[email protected]<mailto:[email protected]>>
> > Sent: Monday, July 20, 2026 1:05 PM
> > To: Christian Hopps <[email protected]<mailto:[email protected]>>
> > Cc: Les Ginsberg (ginsberg)
> > <[email protected]<mailto:[email protected]>>; lsr-chairs
> > <[email protected]<mailto:[email protected]>>; lsr
> > <[email protected]<mailto:[email protected]>>
> > Subject: Re: [Lsr] Re: Adoption of draft-many-lsr-power-group
> >
> > Chris, Les,
> >
> > I wrote that code points "do not require adoption". That is accurate. A
> > 'SHOULD' is not a 'MUST'. You don't get to change it into one. What I
> > wrote originally was correct.
> >
> > I respect the 'SHOULD' and the work the experts do, but the fact of the
> > matter is that we have code, and it is going to ship regardless of
> > adoption. At this point, I cannot stop it.
> >
> > So, this is really up to you. You can allocate, or we can squat. Waiting
> > is out of the question. Your choice?
> >
> > Regards,
> > Tony
> >
> > On Mon, Jul 20, 2026 at 9:56 PM Christian Hopps
> > <[email protected]<mailto:[email protected]>> wrote:
> > Expert hat on: I do not believe Les is raising the bar. We (reg experts)
> > have followed the SHOULD advice rather consistently. We have always pushed
> > for WG adoption first. It’s why I mentioned the order, adoption and then
> > allocate, during the presentation. Yes, SHOULD is not MUST, but it’s also
> > not MAY. :)
> >
> > I think it’s worth giving the normal route a chance here before we look to
> > the exceptional one.
> >
> > Thanks,
> > Chris.
> >
> >
> > On Jul 20, 2026, at 20:12, Tony Li
> > <[email protected]<mailto:[email protected]>> wrote:Les,
> >
> > What I wrote is correct. Please read what you quoted. That's a SHOULD,
> > not a MUST.
> >
> > You don't get to raise the bar on a whim.
> >
> > Tony
> >
> >
> > On Mon, Jul 20, 2026 at 6:36 PM Les Ginsberg (ginsberg) - ginsberg at
> > cisco.com<https://urldefense.com/v3/__http://cisco.com__;!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOkUYhiP1I$><[email protected]<mailto:[email protected]>>
> > wrote:
> > Tony –
> >
> > I don’t want to start an argument – just want to set the record straight.
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fisis-tlv-codepoints%2Fisis-tlv-codepoints.xhtml&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Cf06d61d690364315423908defc968418%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639225920576642649%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O8wTJ%2FkbPXwKL%2FUzwoNmoHT4wYC8qDL5iagbj8fCwB0%3D&reserved=0<https://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.iana.org*2Fassignments*2Fisis-tlv-codepoints*2Fisis-tlv-codepoints.xhtml&data=05*7C02*7Cgunter.van_de_velde*40nokia.com*7Cf06d61d690364315423908defc968418*7C5d4717519675428d917b70f44f9630b0*7C0*7C0*7C639225920576642649*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=O8wTJ*2FkbPXwKL*2FUzwoNmoHT4wYC8qDL5iagbj8fCwB0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOkZD039JA$>
> > states:
> >
> > “Note
> > For IS-IS registries and value ranges maintained via the "Expert
> > Review" [RFC8126] registration procedure, guidance for IESG-designated
> > experts can be found in [RFC7370].”
> >
> > https://www.rfc-editor.org/rfc/rfc7370.html#section-4<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7370.html*section-4__;Iw!!NpxR!n0ezgLOfMsNkRI-J6nztkFXqVqur9Cq9T6Ze1ogGQGCThDoMA3nsEm1IrifeJizVTvEy5_a9nty74EOkD6c3Ri8$>
> > states:
> >
> > “2. The Designated Experts SHOULD only consider requests that arise
> > from I-Ds that have already been accepted as Working Group
> > documents or that are planned for progression as AD Sponsored
> > documents in the absence of a suitably chartered Working Group.”
> >
> > So what you say below is not correct.
> >
> > Les
> >
> > From: Tony Li <[email protected]<mailto:[email protected]>>
> > Sent: Monday, July 20, 2026 8:50 AM
> > To: lsr-chairs <[email protected]<mailto:[email protected]>>
> > Cc: lsr <[email protected]<mailto:[email protected]>>
> > Subject: [Lsr] Adoption of draft-many-lsr-power-group
> >
> > Hi,
> >
> > I would like to formally request that we start an adoption poll of
> > draft-many-lsr-power-group.
> >
> > I would also like to formally request code point assignment for this
> > document. The relevant code points are all under "Expert Review" and do
> > not require formal adoption before code point allocation. We would greatly
> > prefer not to squat on code point values if we do not have to.
> >
> > Regards,
> > Tony
>
>
> _______________________________________________
> Lsr mailing list -- [email protected]<mailto:[email protected]>
> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
