Hi, Sandy, Thank you so very much for all the work on this RFC-to-be! It is great and much appreciated.
Please find my responses, prefaced with [CMP] Thanks! Carlos. > On Aug 27, 2025, at 3:13 PM, Sandy Ginoza <[email protected]> > wrote: > > 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. > [CMP] Thank you for this. Would it be possible to try a different display? [CMP] Top-page: “NC State University & Blue Fern Consulting” or “NC State University / Blue Fern Consulting" [CMP] Authos’ Addresses: “North Carolina State University & Blue Fern Consulting” > > >> 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. [CMP] This is great! > > >> 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. > [CMP] Thank you — I appreciate it. Reviewed and looks good! > > >> 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]. > [CMP] QUIC is good! And removing SNIC is also good. > >> 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. > [CMP] Thanks. > >> 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"? > > [CMP] “emphasis" is appropriate here. > >> 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]. > [CMP] Looks good! > > >> 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. > [CMP] This is great — thanks for using ‘correctly place’ and ’suitable place’ in respective substitutions. > > >> 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. > [CMP] Thank you! It is great! > > >> 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. > [CMP] We are finalizing this discussion and will let you know ASAP. > > >> 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. [CMP] Looks good! > >> <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! [CMP] Thank you again, Sandy!!! Carlos. > Sandy Ginoza > RFC Production Center >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
