Documents, Drafts and I-Ds
### GREEN Chairs & Area Director {#green-chairs--area-director}
Chairs: Diego Lopez, Robert Wilton
### Session link, minutes, jabber {#session-link-minutes-jabber}
Meeting Chat
### IETF 125 GREEN Session Times {#ietf-125-green-session-times}
Monday July 20, 16:30-18:30 Vienna (UTC+2) 14:30-16:30 UTC
Note-takers: Laura Scalone, (add your name here)
New definitions:
Modified definitions:
Rob: We will help you move ahead with the repo
Diego: A couple days ago there was a warning from the datatracker that
the draft was about to expire. Did you modify it?
Emile: Not yet
Diego: It would be interesting to update it, so anyone willing to check
the status of the WG does not get the wrong impression of the work
becoming stalled.
Rob: Are you planning on publishing this as an RFC? It was not
originally planned, and we need to take a decision on this.
Benoît (on chat): On the use case draft, so far, you told us it will not
be published, so we stop investing time trying to improve it. If the
situation has changed, let us know
Robert (on chat): Understood. I don't think that we need to publish it.
The thing that I want to check is to ensure that the WG agrees that the
right use cases are covered and understood.
Changes in v02:
Closed issues (check slides for full list):
Next steps:
Rob: I've had a quick look at the EC document, I think it might be a
minor informative reference. ... We could look into sending an external
liaison.
Diego: I will prepare some text we can use to send such a liaison and
share it on the list
Rob: Regarding the "instantaneous power" issue, my instant reaction here
is that making it optional is better because it's better to give the
flexibility rather than force somebody to have to lie and produce an
incorrect value.
Benoit: Making it optional would not contradict the current definition
we have for "Energy Object"
Nigel Davis: Went through something similar for temperature reporting,
and we ended up deciding that it should be optional, and then we added
extra guidelines to indicate that if it is available then it must be
returned. And this is better than returning inaccurate values.
Benoit: Very good. One more question: Whenever you know the temperature
you have to report it. It could be put it in the YANG, or it could put
it in the document. Do we put it in the YANG module or do we put it in
the document?
Nigel: In that other SDO we had flexibility. Perhaps consider using
profiles. It has to be some normative reference.
Benoit: Do I understand: Guidelines goes in the description and states
that you must report it, and references a profile in the document.
Nigel: In that SDO we end up with a normative reference, which we can
use.
Benoit: This is a bigger discussion right, because actually you're
changing YANG.
Nigel: Not putting a solution forward here, just noting what was done
there.
Robert: I suggest in the end you have a bigger description
Tony Li: Instanenous power as an Int32, do you have a use case for
negative power.
Jan Linblad: What about solar power?
Benoit: That is a good point. Point taken.
Carsten Rossenhoevel: From a testing POV, I'm concerned about optional
fields. I agree that putting something optional is great for adoption,
but longer term it isn't so helpful for conformance. I don't have a good
solution. We could make it conditional. We don't want to allow devices
not to share it.
Benoit: I agree it was my first direction, because it's so easy for
vendors to say I comply because this thing is optional, this is why we
concluded that if you report it, it must be if you can measure it. ...
I'm not going to try to improve something for all the vendors
Carsten: Does this device have the feature to measure? The second point
is about the nameplate power.
Tony: We have serious power in generating instanenous power for every
component, and there is no regulation, and if we can't report a value
then we are not going to report it. How you measure nameplate power
depends on how it is defined (e.g., it may take the worst case power,
e.g., high temp, low airflow)
Benoit: What would you like to report?
Tony: I would like to report nameplate power, it is hard to report
without additional instrymentation
Nigel: On the suggestion of an additional attribute, to say what you do
and don't support.
SoH: Should the base network controller model be scoped to include more
than just power/energy attributes?
Yes: 16
No: 2
NoOp: 5
Rob: It looks very simple, which is good. I think I had some questions
about- there's no dependency on like the topology module because this is
more an external API to either a web interface or web HTTP API, that's
the thing that makes sense
SoH: Have you read/reviewed any version of the PETRA draft
(draft-petra-green-api)?
Yes: 12
No: 12
NoOp: 0
SoH: Do you think that the WG should adopt the petra draft at this time?
Yes: 11
No: 0
NoOp: 16
Rob: I've haven't read in detail, but my instinct is that an
augmentation makes sense.
Jan: If you have a place to do the augmentation then that makes sense.
Carsten: Are you just measuring the power of the sensing function, or
the full device itself.
Muhammad: It would be linked to the sensors.
Carsten: How confident are you of that you can measure sensing
consumption?
Muhammad: I think that it would be possible at least for certain sensing
modes
Carsten: I am not that sure. There two many components in sensing
functionality under different loads
SoH: Have you read/reviewed any version of the ISAC Utilization Draft
(draft-jadoon-green-isac-utilization)?
Yes: 6
No: 23
NoOP: 1
Ben Curtis: Are you able to use these provenance signatures to assess
the source of the energy or the source of the data?
Jan: If the provenance doesn't go all the way then you need to
explain/justify to your auditor.
Diego: In principle, the provenance strings support any kind of sources
of data, whether it is the device measuring or a source of energy
Ben: The second case would be interesting to explore for the departments
of energy.
Mahesh Jethanandani: Asking about GREEN provenance vs the OPSAWG. Not
understanding the difference. The other doc is a device vs controller.
Marisol: When looking at the OPSAWG provenance draft, it is only about
expressing the data signatures. Here we consider additional data to
provide context for these signatures.
Rob: The traffic patterns and the topology seem simplistic to get
detailed conclusions
Luis: Yes. We focused more on metering capabilities
David Silk (on chat): If the PDU is measuring AC input to the router,
and the router is measuring the DC output of the router power supply,
that would explain the 6% discrepency.
Rob: It is not clear to me how this can address the limitiations of the
use of YANG Push
Jinjie: We can discuss this on the list