Hello Sandy, thank you for the updates! It is really taking shape now.
Please see my replies inline (delimited with <ALEX-2>). Carlos, please see item #35 specifically as to whether we need further discussion or if can check it off? Please note that I will be traveling and for all practical purposes offline from this Friday (Aug 29) through Tuesday September 9. Best --- Alex -----Original Message----- From: Sandy Ginoza <[email protected]> Sent: Wednesday, August 27, 2025 12:14 PM To: Carlos Pignataro <[email protected]> Cc: Alexander Clemm <[email protected]>; Alexander Clemm <[email protected]>; RFC Editor <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your review Greetings Authors, Thank you for your thorough replies and your patience. We have updated the document after reviewing the various replies. Please review the updated files and our followup questions listed below. The current files are available here: https://www.rfc-editor.org/authors/rfc9845.xml https://www.rfc-editor.org/authors/rfc9845.txt https://www.rfc-editor.org/authors/rfc9845.pdf https://www.rfc-editor.org/authors/rfc9845.html AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9845-auth48diff.html https://www.rfc-editor.org/authors/rfc9845-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9845-diff.html https://www.rfc-editor.org/authors/rfc9845-rfcdiff.html (side by side) Please review the [rfced] comments in-line below. We have cut items we believe are resolved. Note that we will ask the Document Shepherd to review and approve some of these updates once the text is solidified. Thank you, > > • Is it possible for me two include two affiliations for me? Or does it > need to be only one? Something like this: > • Category: Informational C. > Pignataro, Ed. > ISSN: 2070-1721 NCSU, Blue Fern > • Carlos Pignataro (editor) > North Carolina State University, Blue Fern Consulting > United States of America > Email: [email protected], [email protected] [rfced] Please review the current display and let us know if this is acceptable. > 3) <!--[rfced] Several sentences in the original document that were difficult > to read have been reworded or separated into two sentences. In some cases, a > "FYI" has been added to call your attention to the edit. In general, please > review the edited document closely to make sure that the intended meaning is > intact. In particular, please review Sections 5.3 and 6.1. > --> > > <ALEX> The edits look fine to me. I am surprised to see that you are > substituting "trade-off" for "tradeoff" but if that is the preferred way I > have no issue. > </ALEX> > <Carlos> All edits look good to me [rfced] Regarding “trade-off”, we are using the hyphenated form where it’s being used as a noun. Please see <https://www.merriam-webster.com/dictionary/trade-off> and let us know if you have any questions. <ALEX-2> OK, thank you </ALEX-2> > 4) <!--[rfced] FYI, both "CO2" and "carbon" were used within the same > sentence; for consistency, the latter instance has been updated. > Please let us know if you prefer otherwise. > > Original: > Notable here is the use of fossil fuels, such as oil, > which releases CO2 that had long been removed from the earth's > atmosphere, as opposed to the use of renewable or sustainable fuels > that do not "add" to the amount of carbon in the atmosphere. > > Current: > Notable here is the use of fossil fuels, such as oil, > which releases CO2 that had long been removed from the earth's > atmosphere, as opposed to the use of renewable or sustainable fuels > that do not "add" to the amount of CO2 in the atmosphere. > --> > > <ALEX> This is fine here. > </ALEX> > <Carlos>Actually I think this calls for more precision and clarity > <Carlos>This confuses CO2, GHG, C, and CO2e. > <Carlos>I suggest the following: Please add the following sentence (in green) > in between these two sentences, feel free to fix editorials: > > --- > The science behind greenhouse gas emissions and their relationship > with climate change is complex. However, there is overwhelming > scientific consensus pointing towards a clear correlation between > climate change and a rising amount of greenhouse gases in the > atmosphere. > > > When we say 'greenhouse gases' or GHG, we are referring to gases in the > Earth’s atmosphere that trap heat and contribute to the greenhouse effect. > They include carbon dioxide (CO2), methane (CH4), nitrous oxide (N2O), and > Fluorinated gases (as covered under the Kyoto Protocol and Paris Agreement). > The dominant greenhouse gas in terms of emissions from human activity is CO2, > and consequently, it often becomes shorthand for “all GHGs.” However, other > gases are converted into “CO2-equivalents”, or CO2e. > > One greenhouse gas of particular concern, but by no > means the only one, is carbon dioxide (CO2). Carbon dioxide is > > emitted in the process of burning fuels to generate energy that is > used, for example, to power electrical devices such as networking > equipment. Notable here is the use of fossil fuels, such as oil, > > --- [rfced] We have updated the text per Carlos’s suggestion. Please review and let us know if any updates are needed. <ALEX-2> This looks fine. One small nit for the sentence following in the same paragraph: "Notable here is the use of fossil fuels (such as oil, which releases CO2 that has long been removed from the earth's atmosphere": I would change "has long been removed" to "had long been removed". </ALEX-2> > 13) <!--[rfced] Regarding "Definitions and Acronyms": > > b) Regarding the expansion of "QUIC". We were told by the QUIC WG of the IETF > that it is not an acronym. May this entry be updated as follows or otherwise? > Also, would you like to add RFC 9000 as an informative reference? > > Original: > QUIC: Quick UDP Internet Connections > > Perhaps: > QUIC: the name of a UDP-based, stream-multiplexing, encrypted > transport protocol. > > c) FYI, we removed SNIC from this list because it is not used within this > document. There is one instance of "SmartNICs" > that remains in the document. > > Original: > SNIC: Smart NIC > --> > > RE: b) What you say is correct, agree with that, and we can add RFC > 9000 as informative reference (referenced from that definition) > <Carlos>Agreed [rfced] Please confirm this update is as expected. Current: QUIC: the name of a UDP-based, stream-multiplexing, encrypted transport protocol [RFC9000]. <ALEX-2> This is fine. </ALEX-2> > Re: c) Fine to remove NIC. Re: single use of Smart NIC, should we remove it > (same argument as re:13.a)? <Carlos>I prefer to keep SNIC but I am OK if > removed. > </ALEX> [rfced] We did not remove SNIC per Carlos’s preference. Please let us know if changes are needed. <ALEX-2> Right now, the only place where SNIC occurs is in the acronyms, which seems odd to me. In the interest of not adding to the alphabet soup, since there is only one time is used, it seems to me that just using Smart NIC (without adding SNIC ito the list of acronyms) may be preferable, but I will be go with whatevery your recommendation. </ALEX-2> > 14) <!--[rfced] For readability, may this sentence be rephrased as follows? > Specifically, we suggest rephrasing "emphasis needs to be given to technology" > and making the sentence into shorter ones. > > Original: > As a result, emphasis needs to be given to technology that allows for > example to (at the device level) exercise very efficient and rapid > discovery, monitoring, and control of networking resources so that > they can be dynamically be taken offline or back into service, > without (at the network level) requiring extensive convergence of > state across the network or recalculation of routes and other > optimization problems, and (at the network equipment level) support > rapid power cycle and initialization schemes. > > Perhaps: > As a result, we should prioritize technology that efficiently > discovers, monitors, and controls networking resources at the device > level. This allows devices to be dynamically taken offline or brought > back online without extensive network-level state convergence, route > recalculation, or other complex optimizations. At the network equipment > level, it should also support rapid power cycling and initialization. > > Or: > Technology that has the following characteristics should be prioritized: > * At the device level, it does efficient and rapid discovery, monitoring, > and control of networking resources so they can be dynamically taken > offline or online. > * At the network level, it does not require extensive convergence of > state across the network or recalculation of routes and other > optimization problems. > * At the network equipment level, it supports rapid power cycle and > initialization schemes. > --> > > <ALEX> Agree with breaking up the sentence. I am not sure about the bullet > list - prose may be better here and makes less of an implied claim for > completeness. Refining things a bit further, how about this: > > As a result, emphasis needs to be given to technology that enables, for > example, very efficient and rapid > discovery, monitoring, and control of networking resources. > This allows devices to be dynamically taken offline or brought > back online without extensive network-level state convergence, route > recalculation, or other complex optimizations at the network level. > To facilitate such schemes, rapid power cycle and initialization schemes > should be supported at the device level. > > </ALEX> [rfced] Updated per Alex’s reply, but we wonder if “emphasis" should be “priority"? <ALEX-2> I am fine with either one, whichever you prefer. I would not want to imply that other technology should be deprioritized, hence the preference given to "emphasis", but both are okay. </ALEX-2> > 16) <!--[rfced] FYI, "energy mix powering equipment" has been updated as > follows. Please review whether it conveys the intended meaning. > > Original: > * Methods that allow to account for energy mix powering equipment, > to facilitate solutions that optimize carbon footprint and > minimize pollution beyond mere energy efficiency [Hossain2019]. > > Current: > * Methods that account for equipment that powers an energy mix, to > facilitate solutions that optimize carbon footprint and minimize > pollution beyond mere energy efficiency [Hossain2019]. > --> > > <ALEX> > We are not poweing an energy mix. What is meant is to account / take into > consideration the energy mix of the power sources that generate the > electricity for the equipment. > > Perhaps rephrase as follows: > * Methods that allow to account for the energy mix of the power sources > that are used to power equipment, > in order to facilitate solutions that optimize the actual carbon > footprint and > minimize pollution beyond mere energy efficiency [Hossain2019]. > > > </ALEX> [rfced] The current text reads as follows. Please let us know if any updates are needed. * Methods that allow for the energy mix of the power sources that are used to power equipment to be taken into account, in order to facilitate solutions that optimize the actual carbon footprint and minimize pollution beyond mere energy efficiency [Hossain2019]. <ALEX-2> Looks good, thank you </ALEX-2> > 23) <!--[rfced] Will the term "right-placing" be clear to the reader? > It has not been used before in the RFC series and does not appear in > the dictionary. It appears twice in this document, as follows. > Please consider whether the term should be replaced or explained, as > follows or otherwise. > > Section 6.1: > there are opportunities in right-placing functionality in the network. > > Section 7: > ..., right-placing of computational intelligence, ... > > Perhaps: > > S6.1: there are opportunities for "right-placing" functionality, i.e., > ensuring that it is in the most suitable location for optimal effectiveness. > [or] > there are opportunities for deliberate placement of functionality > within the network. > > S7: ensuring the most suitable placement of computational > intelligence within the network design > --> > > <ALEX> I think the term "right-placing" is fairly well known and I think the > subsequent sentence in 6.1 explains it. That being said, we can of course > expand the text further. > > For 6.1: > > Original: > Likewise, there are opportunities in right-placing functionality in the > network. An example concerns placement of virtualized network functions in > carbon-optimized ways - for example, cohosted on fewer servers in close > proximity to each other in order to avoid unnecessary overhead in > long-distance control traffic. > > Perhaps: > Likewise, there are opportunities in right-placing functionality in the > network, i.e. place functionality in a way that minimizes energy usage > without compromising other aspects of that functionality (such as performance > or utility). An example concerns placement of virtualized network functions > in carbon-optimized ways. For example, virtualized network functions can be > cohosted on fewer servers to achieve higher server utilization, which is more > effective from an energy and carbon perspective than larger numbers of > servers with lower utilization. Likewise, they can be placed in close > proximity to each other in order to avoid unnecessary overhead in > long-distance control traffic. > > For 7: maybe expand slightly, such as: > > ensuring the most suitable placement of computational intelligence > and network functionality within the network design > > </ALEX> [rfced] Carlos replied the following to question 38 (inclusive language): <Carlos>Yes, please replace "right-placing" (there are, I believe, two instances) with something using "correct”. We updated the text with a mix of these suggested updates. Please review and let us know what updates are needed. <ALEX-2> I don't think "right-placing" has the same meaning as "correct". It is not that other placements are incorrect. They are less desirable and arguable less elegant from a holistic perspective, but they are not "incorrect". So, I don't think "correct" is the right term here that catches what we need and this needs to be updated. So, I do believe "right-placing" is a more accurate term and I am not sure why that would be considered offensive by anyone. That said, if you want to replace it, fine, but we need a better alternative. Perhaps "Smart-placing" (I have never seen this used - but the meaning is clear, even if not an established term)? </ALEX-2> > 31) <!--[rfced] Section 8: FYI, we have formatted this list of > questions as a bulleted list. Please let us know if you prefer otherwise. > > Current: > It will also help to answer questions such as: > > * Is caching (with the associated storage) better than > retransmitting from a different server (with the associated > networking cost)? > * Is compression more energy efficient once factoring in the > computation cost of compression vs. transmitting uncompressed > data? > * Which compression scheme is more energy efficient? > * Is energy saving of computing at an efficient hyperscale DC > compensated by the networking cost to reach that DC? > * Is the overhead of gathering and transmitting fine-grained energy > telemetry data offset by the total energy gain resulting from the > better decisions that this data enables? > * Is transmitting data to a Low Earth Orbit (LEO) satellite > constellation compensated by the fact that once in the > constellation, the networking is fueled by solar energy? > * Is the energy cost of sending rockets to place routers in LEO > amortized over time? > --> > > <ALEX> > I think this is fine. Sometimes I am not a big fan of lists as they are > easily interpreted as claiming completeness, which we do not, but I think > it's okay here. Perhaps bullet 3 can be combined / continue bullet 2 (the one > involving compression). > </ALEX> > <Carlos>Can we add text clarifying that the list is not exhaustive? [rfced] We think “such as” indicates that the list is not exhaustive. However, we updated as follows: It will also help to answer questions such as (but not limited to) the following: Please let us know if updates are desired. <ALEX-2> This looks fine <ALEX-2> > 35) <!-- [rfced] We found the following URL for [Telefonica2021]; > would you like to add it or a different URL to this reference? > > https://www.telefonica.com/en/shareholders-investors/financial-reports > /historical-archive-annual-reports/2021/ > > Current: > [Telefonica2021] > Telefonica, "Telefonica Consolidated Annual Report 2021", > 2021. > --> > > <ALEX> > Actual, we would like to point to the most recent report, which is 2024: > https://www.telefonica.com/en/wp-content/uploads/sites/5/2025/03/conso > lidated-management-report.pdf > > > <Carlos>Actually, I disagree here. It is important to point to an earlier / > the FIRST time the Telefónica Annual Report included this. We can *also* > include 2024, but can we please revert back to including 2021 as well? > Thanks!!! > > > The number we are referencing from the report (which can be found now on page > 99) has changed. As a result, the following should be changed in the text: > Original: > For example, in its annual report, Telefónica reports that in 2021, its > network's energy consumption per PB of data amounted to 54MWh > [Telefonica2021]. > > New: > For example, in its annual report, Telefónica reports that in 2024, its > network's energy consumption per PB of data amounted to 38 MWh > [Telefonica2021]. > > </ALEX> [rfced] Please let us know the outcome of this discussion. <ALEX-2> Carlos and I have had multiple iterations over email; the latest proposal as it stands is as follows. Carlos has not yet confirmed his acceptance but not sent a counterproposal either so I am guessing we are getting close. Perhaps we can incorporate it for now, and Carlos please let Sandy know if you want a further change and/or if we need more time to resolve. So, FWIW, this is where things stand: We would like to actually replace the orginal reference with the most current one: [Telefonica2024] Telefonica, "Telefonica Consolidated Annual Report 2024", https://www.telefonica.com/en/wp-content/uploads/sites/5/2025/03/consolidated-management-report.pdf The number we are referencing from the report (which can be found now on page 99) has changed. As a result, we would like to also update the text that follows accordingly. We believe that there is value in comparing this most current number which numbers that were reported earlier all the way back to 2015 in the 2020 version of the report, which we would therefore like to reference as well (in addition to the 2024 version). The reference for this is as follows: [Telefonica2020] Telefonica, "Telefonica Consolidated Annual Report 2020", https://www.telefonica.com/en/shareholders-investors/financial-reports/historical-archive-annual-reports/2020/ With this, the following should be changed in the text: Current: For example, in its annual report, Telefónica reports that in 2021, its network's energy consumption per petabyte (PB) of data amounted to 54 megawatt-hours (MWh) <xref target="Telefonica2021"/>. This rate has been dramatically decreasing (by a factor of seven over six years), although gains in efficiency are being offset by simultaneous growth in data volume. The same report states that an important corporate goal is continuing on that trajectory and aggressively reducing overall carbon emissions further. New: For example, in its annual report, Telefónica reports that in 2024, its network's energy consumption per PB of data amounted to 38 MWh [Telefonica2024]. This rate has been dramatically improving from values that were reported for earlier years, for example 115MWh/PB in 2019 or 400 MWh/PB in 2015 [Telefonica 2020]. While portions of the gains in efficiency are being offset by simultaneous growth in data volume, Telefónica states that an important corporate goal is continuing on that trajectory and aggressively reducing overall greenhouse gas emissions further. One question regarding the references. The annual reports are published early in the following year, i.e. the 2024 report is actually published in 2025. However, it is probably less confusing to use (e.g.) "[Telefonica2024]" instead of "[Telefonica2025]". </ALEX-2> > 37) <!-- [rfced] For [Hossain2019], the URL provided > (https://ieeexplore.ieee.org/document/6779082) is fro an article > titled "Measurement and modeling the power consumption of router > interface". > > We have updated the URL to use the DOI provided in the original > reference. Please let us know if that is not accurate. > > Original: > [Hossain2019] > Hossain, M., Georges, J., Rondeau, E., and T. Divoux, > "Energy, Carbon and Renewable Energy: Candidate Metrics > for Green-Aware Routing?", DOI 10.3390/s19132901, > Sensors Vol. 19 No. 3, June 2019, > <https://ieeexplore.ieee.org/document/6779082>. > > Current: > [Hossain2019] > Hossain, M., Georges, J., Rondeau, E., and T. Divoux, > "Energy, Carbon and Renewable Energy: Candidate Metrics > for Green-Aware Routing?", Sensors, vol. 19, no. 3, > DOI 10.3390/s19132901, June 2019, > <https://doi.org/10.3390/s19132901>. > --> > > <ALEX> > I believe this is correct. Again, Cedric can perhaps double-verify. > </ALEX> [rfced] We have updated the URL and DOI per Cedric’s reply. Please let us know if any updates are needed. <ALEX-2> Looks good to me; thank you! </ALEX-2> > <CEDRIC> > Here's the article: https://hal.science/hal-02169758/ The link in the > "current" doi.org is to another article by different authors. > </CEDRIC> Thank you for your help in resolving the questions above! Sandy Ginoza RFC Production Center -----Original Message----- From: Alexander Clemm <[email protected]> Sent: Monday, August 25, 2025 11:10 PM To: 'Sandy Ginoza' <[email protected]>; 'Carlos Pignataro' <[email protected]> Cc: 'Alexander Clemm' <[email protected]>; 'RFC Editor' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; '[email protected]' <[email protected]> Subject: RE: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your review Hi Sandy, thank you for your update! Carlos and I are still in the process of discussing the response to item #35 and may send you another update for that section once we receive your updated file. Please note that I will be traveling from this Friday (Aug 29) through Tuesday (Sep 9) so it would be great if you could ideally send an updated file by EOB Wednesday that will allow me to turn it around prior to my departure. Thank you and kind regards --- Alex -----Original Message----- From: Sandy Ginoza <[email protected]> Sent: Monday, August 25, 2025 7:39 PM To: Carlos Pignataro <[email protected]> Cc: Alexander Clemm <[email protected]>; Alexander Clemm <[email protected]>; RFC Editor <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your review Greetings all, Thank you for your replies — we are working on an updated file to share with you. In the meantime, here’s some info about whether this is the first document about green/sustainable networking. > @RFC Editor , first, please find three questions/comments: > • Could you please confirm that this is the first RFC being published > about green/sustainable networking? A grep for “green” and “sustainability” included the following: RFC 9657 (Time-Variant Routing (TVR) Use Cases) mentions green computing. https://www.rfc-editor.org/rfc/rfc9657.html RFC 9307 (Report from the IAB Workshop on Analyzing IETF Data (AID) 2021) has a section on Environmental Sustainability. https://www.rfc-editor.org/rfc/rfc9307.html#section-2.5 RFC 9547 (Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022) talks about sustainability. https://www.rfc-editor.org/rfc/rfc9547.html This is not an exhaustive list, but these RFCs seemed the most relevant. Thanks, Sandy Ginoza RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
