I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  
These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last
 call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other 
last call comments.

This draft defines ICMP extensions for power metric related information and four class type has been registered for Environment information.
It is well written, but seems like a good starting point and haven’t been completed yet since you can not envision what else sustainable 
metrics will come. Also I am not sure which working group should be responsible for publishing this draft, maybe some new working group. 
I have the following comments for your consideration:

Major issues:
None.

Minor issues:
1. Introduction said:
“   Using the extension defined herein, a device can explicitly append
these exemplary environmental impact metrics for transmission across
an administrative domain:

 *  Power metrics (e.g., time average, min/max)
*  Electrical Energy Provider or Zone
*  Geolocation
*  Future sustainability metrics
”
Time average, min/max seems not power metrics but time to generate metrics or report metrics or receive metric? So the related question, 
how frequent should these power metrics be reported? When should these power metrics be reported? Does these rely on local policy or 
dynamic configuration?
2. Section 3 Application
My impression is the title of the section 3 is not precise since this section more looks into introduce motivation of this draft. Maybe change
 the title into Motivation?
3. Section 4 said:
“
   For the second task, there is a variety of options available
   depending on use cases.  These can be categorized based on whether
   the approach is distributed (i.e., any endpoint or node can request
   and/or receive the sustainability information) or centralized (i.e.,
   a single 'controller' compiles and consolidates the information.)
   They can also be categorized based on the networking layer used
   (e.g., IP, like ICMP, or application, like SNMP).  Further, an
   existing protocol can be extended, or a brand new protocol can
   potentially be created for this purpose.

”
This is a good analysis for the solution scope, there are many approaches we can take to transport these sustainable information. Have you 
consider in band telemetry protocol or TWAMP or NSH protocol that needed to extended to carry sustainable information? Why ICMP is 
the best option?
Do we need to develop so many different protocol extensions for this?
4. I think terminology lacks consistency, e.g., in someplace we use sustainable information, in some place we use environment impact, in
 some place we use power metrics? What will be the focus of this draft? I am wondering how to position this draft? It is related IAB 
environment impact workshop, it seems also more fit into IETF since we define protocol extensions. My suggestion is to make clear this 
is IETF work so choose the right terminology can avoid ambiguity.
5. Can you provide definition for EERC numbers and also provide reference, can you also provide referenced document or specification 
for the following three terms:
a.  ISO 14001:2015
b.  TCO Certified
c.  Energy-efficient ethernet

6. Section 7 said:
“
Keeping these considerations in mind, we limited the scope of the
transportation of the sustainability metrics to a single
administrative domain.  But, based on [RFC8799], limiting a protocols
functionality doesn't mean that it will be secure.  So, this
particular document, which defines "a modified ICMP message with
sustainability metrics", can be classified as a FAIL-OPEN protocol
[I-D.wkumari-intarea-safe-limited-domains].
”
Interesting statement, I am thinking whether ICMP should consider end to end encryption to address this issue?