[{"author": "Tony Li", "text": "

Good day, all

", "time": "2025-06-16T14:01:42Z"}, {"author": "Robert Wilton", "text": "

I will now restart my laptop to try that.

", "time": "2025-06-16T14:03:30Z"}, {"author": "Diego Lopez", "text": "

I cannot see nor hear you... Truing to reconnect

", "time": "2025-06-16T14:04:50Z"}, {"author": "Beno\u00eet Claise", "text": "

https://datatracker.ietf.org/doc/draft-belmq-green-framework/

", "time": "2025-06-16T14:13:39Z"}, {"author": "Mahesh Jethanandani", "text": "

I do not have audio, as I am on a plane. Will try to follow the slides as much as possible and the chat.

", "time": "2025-06-16T14:18:26Z"}, {"author": "Robert Wilton", "text": "

Link for taking notes: https://notes.ietf.org/notes-ietf-interim-2025-green-02-green?both

", "time": "2025-06-16T14:18:36Z"}, {"author": "Robert Wilton", "text": "

Please all contribute and check that your comments have been captured

", "time": "2025-06-16T14:19:02Z"}, {"author": "Michael Richardson", "text": "

Seems like if the energy consumption is always by abstracted device ID (like a UUID), then if there are multiple measurements (such as one from PoE supply, one from device), then as long as the device is identified, then a collector could take multiple values.

", "time": "2025-06-16T14:27:58Z"}, {"author": "Beno\u00eet Claise", "text": "

As long as the remote UUID is identified, yes. But there is no LLDP over power, hence it's not always discoverable. Sometimes, he has to be set manually. When we have the UUIDs and the relationships (is it monitoring or controlling), then we are good

", "time": "2025-06-16T14:33:05Z"}, {"author": "Diego Lopez", "text": "

In this kind of physical characteristics is where inventories play a key role...

", "time": "2025-06-16T14:34:02Z"}, {"author": "Robert Wilton", "text": "

@Benoit, please can you check that I captured your answer to my question correctly.

", "time": "2025-06-16T14:35:21Z"}, {"author": "Beno\u00eet Claise", "text": "

In this kind of physical characteristics is where inventories play a key role... => where the inventory keys/UUIDs play a key role.

", "time": "2025-06-16T14:36:23Z"}, {"author": "Robert Wilton", "text": "

For this design, we need to think whether augmenting (e.g., inventory) is the best answer. It might be, but this will mean that you will likely always be fetching a lot of data (e.g., all inventory), even if you just want the energy data.

", "time": "2025-06-16T14:39:00Z"}, {"author": "Robert Wilton", "text": "

I think that this is arguably a weakness of YANGs design, or it is being used beyond its original design scope.

", "time": "2025-06-16T14:39:32Z"}, {"author": "Beno\u00eet Claise", "text": "

Rob, using the same UUIDs, yes. Not specifically augmenting.

", "time": "2025-06-16T14:40:53Z"}, {"author": "Beno\u00eet Claise", "text": "

topology: there is the physical one, the power one, the monitoring one and the control one

", "time": "2025-06-16T14:54:10Z"}, {"author": "Stephan Emile", "text": "

+1 for the power one

", "time": "2025-06-16T14:54:32Z"}, {"author": "Marisol Palmero", "text": "

the way that I see it, by default there is aggregation at the device level, if we read directly from the sensors in the device, the polling interval would extrapolate on the energy consumption through the polling frequency... Im not sure this will/can change in the future

", "time": "2025-06-16T14:59:40Z"}, {"author": "Tony Li", "text": "

@Diego Lopez With all due sympathies to your cold, could you please mute? Thx!

", "time": "2025-06-16T15:00:19Z"}, {"author": "Beno\u00eet Claise", "text": "

Chairs, do we want to focus on this question 3 now, instead of jumping between questions?

", "time": "2025-06-16T15:00:48Z"}, {"author": "Diego Lopez", "text": "

@Tony Li, I was not aware I was making any noise, sorry...

", "time": "2025-06-16T15:01:05Z"}, {"author": "Carlos Bernardos", "text": "

I'm sorry but I have to move to another meeting now

", "time": "2025-06-16T15:01:54Z"}, {"author": "Michael Richardson", "text": "

Is it okay to have a power-level 1,2,3... and the device would report what it's forwarding rate would be? Because maybe it depends upon how many ports are active, or how many ACLs are configured?

", "time": "2025-06-16T15:02:38Z"}, {"author": "Michael Richardson", "text": "

For some situations, \"do what you can (and report it), with at most X watts\", and maybe this is because power is limited (a satellite, a ship, an off-grid house...).

", "time": "2025-06-16T15:03:44Z"}, {"author": "Marisol Palmero", "text": "

in POWEFF v00, we introduced the concept of accuracy, it was in the form of a %, based on the vendor implementation

", "time": "2025-06-16T15:04:55Z"}, {"author": "Michael Richardson", "text": "

Michael Richardson said:

\n
\n

For some situations, \"do what you can (and report it), with at most X watts\", and maybe this is because power is limited (a satellite, a ship, an off-grid house...).

\n
\n

\"Mr.O'Brien, re-route all life support power to port-27. The capitain's torrents are troo slow\"

", "time": "2025-06-16T15:07:00Z"}, {"author": "Michael Richardson", "text": "

People figured out that it was better to run your (laptop) CPU at FULL SPEED, and then sleep sooner, rather than run at some slower speed....

", "time": "2025-06-16T15:08:47Z"}, {"author": "Robert Wilton", "text": "

But power consumption for a CPU isn't linear to performance. E.g., 2 times power = 25% more performance. On battery you may not want that extra 25% performance because it will burn a lot more energy to complete the same work.

", "time": "2025-06-16T15:10:43Z"}, {"author": "Tony Li", "text": "

Some POPs have battery backup so that when the mains fail, you're still powered. The device may not be aware if it's on battery power.

", "time": "2025-06-16T15:13:59Z"}, {"author": "Jan Lindblad", "text": "

@Emile, in the best use of power in laptops is controlled by a \"energy management controller\" process. So if we have an API where the controller can reason with components about their performance, this battery optimization can be built.

", "time": "2025-06-16T15:14:59Z"}, {"author": "Diego Lopez", "text": "

Tony, they could be put on one of these pre-defined states (\"running on batteries\")

", "time": "2025-06-16T15:15:49Z"}, {"author": "Tony Li", "text": "

Ok, if you want that. BTW, this situation can happen independently on each power input and some devices have redundant power inputs.

", "time": "2025-06-16T15:18:44Z"}, {"author": "Tony Li", "text": "

A UUID per component seems like pointless overkill.

", "time": "2025-06-16T15:19:38Z"}, {"author": "Diego Lopez", "text": "

Agreed!

", "time": "2025-06-16T15:19:46Z"}, {"author": "Jan Lindblad", "text": "

@Robert, as someone who has already worked on YANG modules, I of course thing the time is right to work on them. But the list of questions is highly relevant and should be worked on before modeling, imho.

", "time": "2025-06-16T15:30:09Z"}, {"author": "Reshad Rahman", "text": "

https://datatracker.ietf.org/doc/statement-iesg-on-design-teams-20011221/

", "time": "2025-06-16T15:31:17Z"}, {"author": "Diego Lopez", "text": "

Jan, don't you think we have to address those open questions while we model?

", "time": "2025-06-16T15:31:40Z"}, {"author": "Jan Lindblad", "text": "

Sure, we can (and to some extent, have) do that

", "time": "2025-06-16T15:32:01Z"}, {"author": "Diego Lopez", "text": "

Reshad, I believe we have followed what is requested in the statement...

", "time": "2025-06-16T15:32:47Z"}, {"author": "Michael Richardson", "text": "

This group is not so big that you need split off a design team.

", "time": "2025-06-16T15:33:56Z"}, {"author": "Beno\u00eet Claise", "text": "

Diego, that would work!

", "time": "2025-06-16T15:35:01Z"}, {"author": "Diego Lopez", "text": "

Michael, it is more about the different base models we have on the table...

", "time": "2025-06-16T15:35:55Z"}, {"author": "Michael Richardson", "text": "

Tony Li said:

\n
\n

Some POPs have battery backup so that when the mains fail, you're still powered. The device may not be aware if it's on battery power.

\n
\n

I have a DC where there is diesel backup, but no batteries. So we struggle to balance per-cabinet UPS to last the ~8min while the diesel comes online. Once backup is started, it's not clear we need to save any power, but it sure would be nice to go to some 25% power utilitization for 8 minutes, even if we drop some packets. Our UPS can't tell if they are on diesel or not, but they do know when they have nothing.

", "time": "2025-06-16T15:37:18Z"}, {"author": "Tony Li", "text": "

Our model needs to be able to capture that. :-)

", "time": "2025-06-16T15:38:56Z"}, {"author": "Michael Richardson", "text": "

Some group should meet every two weeks. It doesn't matter (at the size of the group), what you call it. CBOR/CORE's every two week meeting are essentially design team meetings, but called virtual-interims. ANIMA's weekly BRSKI design team meeting is not a virtual interim, we do not have slides... and we focus on a shared github issue tracker.

", "time": "2025-06-16T15:41:42Z"}, {"author": "Beno\u00eet Claise", "text": "

Should the chairs try and drive discussion/closer on specific key questions on the list? => Should the chairs try and drive discussion/closer on specific key questions

", "time": "2025-06-16T15:42:33Z"}, {"author": "Beno\u00eet Claise", "text": "

Absolutely

", "time": "2025-06-16T15:42:37Z"}, {"author": "Michael Richardson", "text": "

Perhaps you could bring one or two of these smart PDU?

", "time": "2025-06-16T15:49:13Z"}, {"author": "Robert Wilton", "text": "

Luis, you may want to contact the IETF NOC if you need anything specific from a network access POV.

", "time": "2025-06-16T15:50:41Z"}, {"author": "Beno\u00eet Claise", "text": "

This is on the WIKI: https://wiki.ietf.org/en/meeting/123/hackathon

", "time": "2025-06-16T15:53:36Z"}, {"author": "Reshad Rahman", "text": "

Diego, just saw your response. yes you are, all good. I was just sharing in case some people aren't aware of how design teams work.

", "time": "2025-06-16T15:56:14Z"}, {"author": "Luis Contreras", "text": "

@Michael -> that is the idea, but let's see how feasible is

", "time": "2025-06-16T15:56:15Z"}, {"author": "Luis Contreras", "text": "

@Rob -> thanks, great suggestion, we will contact them

", "time": "2025-06-16T15:56:39Z"}]