Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] In the abstract, rather than "in no insignificant way", we suggest making the sentence more direct. Is this update acceptable? Original: On the other hand, they contribute to this footprint themselves in no insignificant way. Suggested: On the other hand, they significantly contribute to this footprint themselves. --> 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. --> 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. --> 5) <!--[rfced] The phrase "as well as land use" doesn't parse in this sentence. Is the intended meaning that it minimizes the land area that is used? Does the suggested text convey the intended meaning? Original: IoT applications that facilitate automated monitoring and control from remote sites help make agriculture more sustainable by minimizing the application of resources such as water and fertilizer as well as land use. Perhaps: IoT applications that facilitate automated monitoring and control from remote sites help make agriculture more sustainable by minimizing the usage of water, fertilizer, and land area. --> 6) <!-- [rfced] For clarity, may we update this sentence as follows? Original: An often-considered gain in networking sustainability can be made with regards to improving the efficiency with which networks utilize power during their use phase, reducing the amount of energy that is required to provide communication services. Perhaps: Reducing the amount of energy that is required to provide communication services and improving the efficiency with which networks utilize power during that use phase are both often considered gains in networking sustainability. Or: As often discussed, networking sustainability can be improved by increasing the efficiency with which networks utilize power during their use phase, reducing the amount of energy that is required to provide communication services. --> 7) <!--[rfced] In general, please review how the terms "green", "greener", etc., are used in this document and let us know if any updates are needed. Specifically: a) Inconsistent usage of quotation marks in the original "green" 3 instances vs. 5 without quotes "greener" 7 instances vs. 18 without quotes "greenness" 1 instance vs. 1 without quotes We note that "greener" is in quotes in the abstract, then used frequently in the body of the document without quotes. Is there a rationale for when it is with vs. without quotes? b) Section 3: "greener" seems redundant with the surrounding text, in light of the definition of "green" provided in Section 1.1. May it be removed? Original: for greener, more sustainable, less carbon-intensive networks. Perhaps simply: for more sustainable, less carbon-intensive networks. c) Section 6.2: Will it be clear to the reader what "green billing and charging schemes" means? --> 8) <!--[rfced] Does "Management" refer to "network management" in the first sentence of this paragraph? If so, we suggest updating it for clarity. Original: Management has an outsized role to play in approaching those problems. Perhaps: Network management has an outsized role to play in approaching those problems. --> 9) <!--[rfced] For readability and to avoid the odd phrasing "maximize ways in which they eliminate the use of", we suggest rephrasing as follows. Original: To reduce the amount of energy used, network providers need to maximize ways in which they make use of scarce resources and eliminate use of resources which are not needed. Perhaps: To reduce the amount of energy used, network providers need to eliminate the use of unneeded resources and maximize the use of scarce resources. --> 10) <!--[rfced] Please clarify "motions" in this text. Does it refer to mechanisms, processes, or something else? Original: - Hardware: Reducing embedded carbon during material extraction and manufacturing, improving energy efficiency and reducing energy consumption during operations, and reuse, repurpose, and recycle motions. Perhaps: - Hardware: Reducing embedded carbon during material extraction and manufacturing; improving energy efficiency and reducing energy consumption during operations; and improving mechanisms for reusing, repurposing, and recycling hardware. --> 11) <!--[rfced] FYI, this has been rephrased for clarity. Specifically, this removes the redundancy of "management functionality" and "manage the network". Original: To fully tap into the potential of such features requires accompanying management functionality, for example to determine when it is "safe" to down-speed a link or enter a power saving mode, and manage the network in such a way that conditions to do so are maximized. Current: To tap into the potential of such features, it requires accompanying management functionality, for example, to determine when it is "safe" to down-speed a link or to enter a power-saving mode, and to maximize the conditions when that action is appropriate. --> 12) <!--[rfced] Please review the intended meaning of this sentence. Instead of "and", should it be "because"? Also, would 'rated less "green"' be more clear with a rephrase? Original: Likewise, some networking devices may be rated less "green" and more power-intensive than others or powered by less-sustainable energy sources. Perhaps: Likewise, some networking devices may be given a lower sustainability rating because they are more power-intensive or are using less-sustainable energy sources. --> 13) <!--[rfced] Regarding "Definitions and Acronyms": a) Does "IPU" refer to Intel's IPU specifically? If so, we suggest updating the definition or the usage within the document (one instance). Searches for this term outside the RFC series (e.g., on dl.acm.org, ieeexplore.ieee.org) give results such as "Intel's IPU". Current: IPU: Infrastructure Processing Unit 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 --> 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. --> 15) <!--[rfced] Please clarify the phrase "eco-friendly to deploy"; could a more precise term than "eco-friendly" be used in this context? Original: Making such equipment more power efficient, have it dissipate less heat to consume less energy and reduce the need for cooling, making it eco-friendly to deploy, sourcing sustainable materials and facilitating recycling of equipment at the end of its lifecycle all contribute to making networks greener. --> 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]. --> 17) <!--[rfced] FYI, we updated these terms as follows, based on their usage in other documents (including on ieeexplore.ieee.org and dl.acm.org). Please review. Also, we removed "(MLU)" because the acronym is not used within this document. Original: Maximal Link Utilization (MLU) minimal link utilization Current: Maximum Link Utilization Minimum Link Utilization --> 18) <!--[rfced] FYI, we updated "in the limit" to "in an extreme case" here. Please let us know if that is not the intended meaning. Current: This should be done carefully: in an extreme case, a high rate of transmission over a short period of time may create bursts that the network would need to accommodate, with all attendant complications of bursty traffic. --> 19) <!--[rfced] For the ease of the reader, would you like to add a definition for "Shannon limit"? For example, perhaps it's referring to [Shannon] as referenced in RFC 6386. Original: At the application layer, protocols may also use coding mechanisms that encode information close to the Shannon limit. --> 20) <!--[rfced] FYI, we updated this sentence as follows to clarify "(of course being offset by increasingly higher resolution)"; please review. Is it accurate the savings are offset by the energy demands of increasingly higher resolution? Original: Currently, most of the traffic over the Internet consists of video streaming and encoders for video are already quite efficient and keep improving all the time, resulting in energy savings as one of many advantages (of course being offset by increasingly higher resolution). Current: Currently, most of the traffic over the Internet consists of video streaming, and video encoders are already quite efficient and keep improving all the time. This results in energy savings as one of many advantages, although of course the savings are offset by increasingly higher resolution. --> 21) <!--[rfced] May this item be rephrased as follows? The original list reads as "reduction in improvements in coding", which does not seem intended. Original: * Protocol advances for improving the ratio of goodput to throughput and to reduce waste: reduction in header tax, in protocol verbosity, in need for retransmissions, improvements in coding, etc. Perhaps: * Protocol advances for improving the ratio of goodput to throughput and to reduce waste; this could include coding improvements as well as reductions in the header tax, the protocol verbosity, and the need for retransmissions. --> 22) <!--[rfced] "energy footprint" vs. "carbon footprint" In Section 5.4, the first paragraph uses the former, whereas the summary uses the latter. Is this accurate? Note: "energy footprint" only appears twice in this document; please consider whether "energy consumption" is more accurate. Original: From an energy footprint perspective, ... [...] * Devise methods to assess the magnitude of the carbon footprint that is associated with addressing schemes. --> 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 --> 24) <!--[rfced] Please clarify what "This" refers to in each instance. Perhaps first "This" is weaning, and the second "This" is load-balancing. May it be significantly rephrased as shown below? Original: Therefore, weaning such resources from traffic becomes an important consideration for energy- efficient traffic steering. This contrasts and indeed conflicts with existing schemes that typically aim to create redundancy and load- balance traffic across a network to achieve even resource utilization. This usually occurs for important reasons, such as making networks more resilient, optimizing service levels, and increasing fairness. Perhaps: Therefore, weaning resources from traffic is an important consideration for energy-efficient traffic steering. This approach conflicts with existing schemes that typically aim to increase network resilience, optimize service levels, and ensure fairness by creating redundancy and load-balancing traffic for even resource utilization. --> 25) <!--[rfced] FYI, this sentence has been updated as follows for readability. Please review whether it conveys your intended meaning, and whether you prefer the shorter alternative. Original: One of the big challenges hence concerns how resource weaning schemes to realize energy savings can be accommodated while preventing the cannibalization of other important goals, counteracting other established mechanisms, and avoiding destabilization of the network. Current: Thus, a big challenge is how resource-weaning schemes to realize energy savings can be accommodated without cannibalizing other important goals, counteracting other established mechanisms, or destabilizing the network. Or even shorter: Thus, a big challenge is implementing resource-weaning for energy savings without cannibalizing other important goals, counteracting other established mechanisms, or destabilizing the network. --> 26) <!--[rfced] Section 6.2: What was intended here, rather than 'latter' twice? Original: (Note: there may be a differential in running a computation at an edge server vs. at an hyperscale DC. The latter is often better optimized than the latter.) Perhaps: [The first sentence remains the same.] The latter is often better optimized than the former. --> 27) <!--[rfced] Please clarify "a particularly poor carbon footprint" here. Does it mean a large carbon footprint? If so, we suggest replacing the word "poor", which could be interpreted as "weak" or "substandard". Original: Does the path include outliers, i.e., segments with equipment with a particularly poor carbon footprint? Perhaps: Does the path include outliers, i.e., segments with equipment with a particularly large carbon footprint? --> 28) <!--[rfced] The term "sustainability visibility" reads oddly. Please review if the updated sentence conveys the intended meaning. The phrase "visibility into energy consumption" (a concept from Section 4) has been used. Original: As we desire to add carbon and energy awareness into networks, the energy proportionality of topologies directly supports sustainability visibility and improvements via automation. Current: To add carbon and energy awareness into networks, the energy proportionality of topologies directly supports visibility into energy consumption and improvements via automation. --> 29) <!--[rfced] FYI, this sentence has been updated as follows to clarify the phrase "help its realization". Seemingly this phrase refers to help the realization of such architectures. Please review. Original: Softwarization, containers, microservices are direct enablers for such architectures, and the deployment of programmable network infrastructure (as for instance Infrastructure Processing Units - IPUs or SmartNICs that offload some computations from the CPU onto the NIC) will help its realization. Current: Softwarization, containers, and microservices are direct enablers of such architectures. Their realization will be further aided by the deployment of programmable network infrastructure, such as Infrastructure Processing Units (IPUs) or SmartNICs that offload some computations from the CPU onto the NIC. --> 30) <!--[rfced] "green footprint" (one instance) You might want to consider a different term. Original: * Investigate organization of networking architecture for important classes of applications (examples: content delivery, right-placing of computational intelligence, industrial operations and control, massively distributed machine learning and AI) to optimize green foot print and holistic approaches to trade off carbon footprint between forwarding, storage, and computation. --> 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? --> 32) <!--[rfced] In order to clarify the phrase "by the fact that once in the constellation", please consider whether the updated text conveys the intended meaning. Original: 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? Perhaps: * Is the energy cost of transmitting data to a Low Earth Orbit (LEO) satellite constellation offset by the networking of that constellation being powered by solar energy? Or: * Does the energy saved by a Low Earth Orbit (LEO) satellite constellation, which is powered by solar energy, offset the energy required to transmit data to it? --> 33) <!-- [rfced] Informative reference RFC 2481 has been obsoleted by RFC 3168. We recommend replacing RFC 2481 with RFC 3168; is that acceptable? It is cited only once in the original: ECN [RFC2481] is a possible solution, however, it is not widely deployed. --> 34) <!-- [rfced] FYI - We have updated the following references to include DOIs and added URLs. Please let us know if you have any objections or clarifications. [Ahlgren2012survey] [Alizadeh2010DCTCP] [Bianco2016energy] [Bolla2011energy] [Chabarek08] [DRAM] [Emergy] [Framework] [GreenNet22] [Herzen2011PIE] [Islam2012evaluating] [Junkyard] [Krol2017NFaaS] [Mathew2011energy] [NewClass] [QUAL] [Ren2018jordan] [SideChannel] [TCC] [TradeOff] [Westphal2021qualitative] [Wolf2014choicenet] --> 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. --> 36) <!-- [rfced] FYI, for [Cervero19], we updated the year from 2019 to 2015 to match the year found at the DOI. Please let us know if that is not accurate. Current: [Cervero15] Cervero, A. G., Chincoli, M., Dittmann, L., Fischer, A., Garcia, A., Galán-Jiménez, J., Lefevre, L., Meer, H. D., Monteil, T., Monti, P., Orgerie, A., Pau, L., Phillips, C., Ricciardi, S., Sharrock, R., Stolf, P., Trinh, T., and L. Valcarenghi, "Green Wired Networks", Large-Scale Distributed Systems and Energy Efficiency, pp. 41-80, DOI 10.1002/9781118981122.ch3, 2015, <https://doi.org/10.1002/9781118981122.ch3>. --> 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>. --> 38) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. In addition, please consider whether "tradition" should be updated for clarity. It can be ambiguous. Section 6.1: Optimizing cost has a long tradition in networking; --> 39) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> Thank you. RFC Editor/ar On Aug 15, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/08/15 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9845.xml https://www.rfc-editor.org/authors/rfc9845.html https://www.rfc-editor.org/authors/rfc9845.pdf https://www.rfc-editor.org/authors/rfc9845.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9845-diff.html https://www.rfc-editor.org/authors/rfc9845-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9845-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9845 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9845 (draft-irtf-nmrg-green-ps-06) Title : Challenges and Opportunities in Management for Green Networking Author(s) : A. Clemm, Ed., C. Pignataro, Ed., C. Westphal, L. Ciavaglia, J. Tantsura, M. Odini -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
