Hi, thank you for your thorough review and excellent editorial suggestions! Please find my responses inline, <ALEX>.
In the interest of quick turnaround, we did not first coordinate amongst the authors, but I don't think there is anything controversial so I just decided to go ahead. Cedric, there are two items (36 and 37) where you may want to doublecheck my response. Kind regards --- Alex -----Original Message----- From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> Sent: Friday, August 15, 2025 8:28 PM To: lud...@clemm.org; cpign...@gmail.com; westp...@ieee.org; laurent.ciavag...@nokia.com; jefftant.i...@gmail.com; mp.od...@orange.fr Cc: rfc-edi...@rfc-editor.org; i...@irtf.org; jerome.franc...@uni.lu; auth48archive@rfc-editor.org Subject: Re: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your review 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. --> <ALEX> Sustainability Sustainable Networking </ALEX> 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. --> <ALEX> OK </ALEX> 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> 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> 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. --> <ALEX> This is fine. Maybe just make it "land" instead of "land area"? </ALEX> 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. --> <ALEX> How about this: One way in which gains in network sustainability can be achieved involves reducing the amount of energy needed to provide communication services and improving the efficiency with with networks utilize power during their use phase. </ALEX> 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? --> <ALEX> re: a) The reason to have "green" in quotes is that it is such a colloquial descriptive yet vague term. But you are certainly correct regarding the need for consistency. Looking at the text, perhaps we should keep the first occurrence of green in quotes and afterwards use the term without quotes. I.e., we keep it here: In the context of this document, we refer to networking technology that helps to improve its own networking sustainability as "green". Afterwards we remove the quotes. As for greener, use the same policy: Keep the first instance in quotes: Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. Afterwards remove the quotes. Same for greenness. Put greenness into quotes here: Energy-efficiency and "greenness" are aspects that are rarely considered when designing network protocols. Afterwards remove it. Would that work? re: b) yes, it's arguably redundant, but I would keep it for emphasis re: c) To make it clearer, how about rephrasing it as follows: Original: That might serve many purposes beyond network optimization, from the option to introduce green billing and charging schemes to the ability to raise carbon awareness by end users. Perhaps: That might serve many purposes beyond network optimization, from the option to introduce green billing and charging schemes that account for the amount of carbon emissions that are attributed to the use of communication services by particular users to the ability to raise carbon awareness by end users. </ALEX> 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. --> <ALEX> This is fine. </ALEX> 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. --> <ALEX> We should emphasize the theme of optimization in here, so I would want to lead with that. Maybe swap it around a bit to become something like this: To reduce the amount of energy used, network providers need to maximize the use of scarce resources and eliminate the use of resources that are not strictly needed. </ALEX> 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. --> <ALEX> It refers to all of the above. How about: - Hardware: Reducing embedded carbon during material extraction and manufacturing; improving energy efficiency and reducing energy consumption during operations; and increasing reuse, repurposing, and recycling. </ALEX> 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. --> <ALEX> I think I like the original better. If you don't like the redundancy of "manage", perhaps use "operate", to result in this: 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 operate the network in such a way that conditions to do so are maximized. </ALEX> 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. --> <ALEX> The "because" is not correct - there is no causality here and it is not about how sustainability ratings are assigned but how they are used The next sentence basically states that the use of devices that have low ratings or that use dirty sources should be avoided. If you want to rephrase for greater clarity how about this: Likewise, some networking devices may have a lower sustainability rating, be less energy-efficient, or be powered less-sustainable energy sources than others. </ALEX> 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 --> <ALEX> Re: a) This is not specific to Intel but a general use of the term. However, there is only a single instance in the text in which it occurs. If it is acceptable, I guess the most appropriate thing to do is to remove it? RE: b) What you say is correct, agree with that, and we can add RFC 9000 as informative reference (referenced from that definition) Re: c) Fine to remove NIC. Re: single use of Smart NIC, should we remove it (same argument as re:13.a)? </ALEX> 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> 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. --> <ALEX> How about just removing it, to result in this: Making such equipment more power efficient, have it dissipate less heat to consume less energy and reduce the need for cooling, sourcing sustainable materials and facilitating recycling of equipment at the end of its lifecycle all contribute to making networks greener. </ALEX> 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> 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 --> <ALEX> Thank you, this looks good </ALEX> 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. --> <ALEX> This is referring to the transmission limit, but I think your suggestion reads more or less fine. Or perhaps more simply: This should be done carefully: a sudden very 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. </ALEX> 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. --> <ALEX> Good suggestion. Yes, the reference is [Shannon] Shannon, C., "A Mathematical Theory of Communication", Bell System Technical Journal Vol. 27, pp. 379-423 and 623-656, July and October 1948. </ALEX> 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. --> <ALEX> The degree to which higher resolution video really contributes to less sustainable networks is subject to controversial discussion. Perhaps phrase it as follows: Currently, most of the traffic over the Internet consists of video streaming. Video encoders are already quite efficient and keep improving all the time. This results in energy savings as one of many benefits, even if some of those savings may be partially offset by increasingly higher resolution. </ALEX> 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. --> <ALEX> This is fine but I don't like the "could include", perhaps better as follows: * Protocol advances for improving the ratio of goodput to throughput and to reduce waste; this includes advances such as coding improvements, reductions in header tax, lower protocol verbosity, and reduced need for retransmissions. </ALEX> 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. --> <ALEX> To eliminate the mention of energy footprint, perhaps we can rephrase things as follows: Original: Address tables can get very large, resulting in large forwarding tables that require considerable amount of memory, in addition to large amounts of state needing to be maintained and synchronized. From an energy footprint perspective, both can be considered wasteful and offer opportunities for improvement. Suggested: Address tables can get very large, resulting in large forwarding tables that require considerable amount of memory, in addition to large amounts of state needing to be maintained and synchronized. Memory as well as the processing needed to maintain and synchronize state both consume energy. Exploring ways to reduce the amount of memory and synchronization of state that is required offers opportunities to reduce energy use. For the second instance, we can simply replace "energy footprint" with "carbon footprint": Original: As part of this, aspects such as the impact of deploying new protocols on the rate of obsolescence of existing equipment should be considered. For instance, incremental approaches that do not require to replace equipment right away - or even extend the lifetime of deployed equipment - would have a lower energy footprint. Suggested: As part of this, aspects such as the impact of deploying new protocols on the rate of obsolescence of existing equipment should be considered. For instance, incremental approaches that do not require to replace equipment right away - or even extend the lifetime of deployed equipment - would result in a lower carbon footprint. </ALEX> 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> 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. --> <ALEX> Fine with rephrsasing, but I think the conflict is not that the other schemes aim to optimize service levels etc but the ways in which this gets achieved, i.e. "spreading out" (versus concentrating) if energy is not a concern. How about: Therefore, weaning resources from traffic is an important consideration for energy-efficient traffic steering. This approach contrasts and indeed conflicts with existing schemes that typically aim to to create redundancy and load- balance traffic across a network to achieve even resource utilization across larger numbers of network resources as a means to increase network resilience, optimize service levels, and ensure fairness. </ALEX> 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. --> <ALEX> Both sound fine. My preference is the slightly longer version ("Current:") </ALEX> 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. --> <ALEX> Yes, good catch. Thank you! </ALEX> 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? --> <ALEX> Basically, it means "bad". The update is fine. </ALEX> 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. --> <ALEX> You are correct that this part reads oddly. I am not sure energy proportionality of topologies should even be mentioned in this context (and if it is, it might require further explanation). How about simply: As part of adding carbon and energy awareness into networks, it is useful also for topology information to provide visibility into sustainability data. Such capabilities can help to assess of sustainability of the network overall and can enable automated applications to improve it. ? </ALEX> 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. --> <ALEX> I think this is fine. Is it clear enough that "their" refers to the architectures, not to the containers? Or perhaps a bit of ambiguity is okay in this context (cannot think of a better alternative now). </ALEX> 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. --> <ALEX> OK, how about replacing it with "overall sustainability", to result in the following: * 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 overall sustainability and holistic approaches to trade off carbon footprint between forwarding, storage, and computation. </ALEX> 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> 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? --> <ALEX> How about this: * Is the energy cost needed to transmit data to a Low Earth Orbit (LEO) satellite constellation offset by the fact that the constallation and any networking within it are powered by solar energy? </ALEX> 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. --> <ALEX> Yes, good catch, thank you. </ALEX> 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] --> <ALEX> Very nice, thank you </ALEX> 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 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> 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>. --> <ALEX> I think your update looks correct. (Perhaps Cedric, who brought this reference, may want to verify as well) </ALEX> 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> 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; --> <ALEX> I don't see what would be controversial/non-inclusive about this statement, can you please enlighten me? That being said, if you want to change it to something like "Optimizing cost has long been an area of focus in networking", that's fine. </ALEX> 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. --> <ALEX> I think it is fine to delete them. </ALEX> 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
