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. > 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. > 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]. > 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. > 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"? > 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]. > 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. > 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. > 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/consolidated-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. > 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. > <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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
