Sorry, hit sent too quickly, without saying that this were my response to the comments, for points 35 and 36 below (as <CEDRIC> ...</CEDRIC>. Hopefully it's clear enough, but let me know if you have any questions.
C. On Wed, Aug 20, 2025 at 2:36 PM Cedric Westphal <cwestp...@gmail.com> wrote: > > On Tue, Aug 19, 2025 at 3:03 PM Alexander Clemm <lud...@clemm.org> wrote: > > > > 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> > > 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> > > <CEDRIC> > 2015 is correct > </CEDRIC> > > > > 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>. > > --> > > > <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> > > > > 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
