Dear RFC Editorial Team, Thank you very much for the comprehensive review,
and associated suggestions and comments,
Thank you, Alex, for taking the first pass at these responses.
@RFC Editor <rfc-edi...@rfc-editor.org> , first, please find three
questions/comments:
1. Could you please confirm that this is the first RFC being published
about green/sustainable networking?
2. Is it possible for me two include two affiliations for me? Or does it
need to be only one? Something like this:
- Category: Informational C.
Pignataro, Ed.
ISSN: 2070-1721 NCSU, Blue Fern
- Carlos Pignataro (editor)
North Carolina State University, Blue Fern Consulting
United States of America
Email: cmpig...@ncsu.edu, carlos@bluefern.consulting
3. There is an instance of "greenhouses gases" that was missed and
needs to be corrected to say "*greenhouse gases"*
@RFC Editor <rfc-edi...@rfc-editor.org> , please find inline my additions
on top of Alex' responses, inline, with '*<Carlos> Bold green'*
@Alexander Clemm <a...@clemm.org>
* , please see Item #35, one disagreement.*
On Tue, Aug 19, 2025 at 6: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>
>
*<Carlos>Please add:*
*Environmental Sustainability*
*Green Networking*
>
> 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>
> *<Carlos>OK*
> 3) <!--[rfced] Several sentences in the original document that were
> difficult to read have been reworded or separated into two sentences. In
> some cases, a "FYI" has been added to call your attention to the edit. In
> general, please review the edited document closely to make sure that the
> intended meaning is intact. In particular, please review Sections 5.3 and
> 6.1.
> -->
>
> <ALEX> The edits look fine to me. I am surprised to see that you are
> substituting "trade-off" for "tradeoff" but if that is the preferred way I
> have no issue.
> </ALEX>
> *<Carlos> All edits look good to me*
> 4) <!--[rfced] FYI, both "CO2" and "carbon" were used within the same
> sentence; for consistency, the latter instance has been updated.
> Please let us know if you prefer otherwise.
>
> Original:
> Notable here is the use of fossil fuels, such as oil,
> which releases CO2 that had long been removed from the earth's
> atmosphere, as opposed to the use of renewable or sustainable fuels
> that do not "add" to the amount of carbon in the atmosphere.
>
> Current:
> Notable here is the use of fossil fuels, such as oil,
> which releases CO2 that had long been removed from the earth's
> atmosphere, as opposed to the use of renewable or sustainable fuels
> that do not "add" to the amount of CO2 in the atmosphere.
> -->
>
> <ALEX> This is fine here.
> </ALEX>
> *<Carlos>Actually I think this calls for more precision and clarity*
*<Carlos>This confuses CO2, GHG, C, and CO2e.*
*<Carlos>I suggest the following: Please add the following sentence (in
green) in between these two sentences, feel free to fix editorials:*
*---*
The science behind greenhouse gas emissions and their relationship
with climate change is complex. However, there is overwhelming
scientific consensus pointing towards a clear correlation between
climate change and a rising amount of greenhouse gases in the
atmosphere.
* When we say 'greenhouse gases' or GHG, we are referring to gases
in the Earth’s atmosphere that trap heat and contribute to the
greenhouse effect. They include carbon dioxide (CO2), methane (CH4),
nitrous oxide (N2O), and Fluorinated gases (as covered under the Kyoto
Protocol and Paris Agreement). The dominant greenhouse gas in terms of
emissions from human activity is CO2, and consequently, it often
becomes shorthand for “all GHGs.” However, other gases are converted
into “CO2-equivalents”, or CO2e.*
One greenhouse gas of particular concern, but by no
means the only one, is carbon dioxide (CO2). Carbon dioxide is
emitted in the process of burning fuels to generate energy that is
used, for example, to power electrical devices such as networking
equipment. Notable here is the use of fossil fuels, such as oil,
*---*
>
> 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>*<Carlos>Agreed*
>
> 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>*<Carlos>Alex' edit works.*
>
> 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? *<Carlos>I like this approach*
>
> re: b) yes, it's arguably redundant, but I would keep it for emphasis
> *<Carlos>I'd
> keep green here, please.*
>
> 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 *equivalent *emissions that are attributed to the use of
> communication services by particular users to the ability to raise carbon
> awareness by end users.
> </ALEX>
> *<Carlos>Note I added "equivalent"*
>
> 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.*<Carlos>Yes.*
> </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? *<Carlos>Agreed*
> RE: b) What you say is correct, agree with that, and we can add RFC 9000
> as informative reference (referenced from that definition)
> *<Carlos>Agreed*
> Re: c) Fine to remove NIC. Re: single use of Smart NIC, should we remove
> it (same argument as re:13.a)? *<Carlos>I prefer to keep SNIC but I am OK
> if removed.*
> </ALEX>
>
>
> 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>
> *<Carlos>Exactly!*
> 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>
>
*<Carlos>Can we add text clarifying that the list is not exhaustive?*
>
> 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>*<Carlos>Thank you for this!!!*
>
> 35) <!-- [rfced] We found the following URL for [Telefonica2021];
> would you like to add it or a different URL to this reference?
>
>
> https://www.telefonica.com/en/shareholders-investors/financial-reports/historical-archive-annual-reports/2021/
>
> Current:
> [Telefonica2021]
> Telefonica, "Telefonica Consolidated Annual Report 2021",
> 2021.
> -->
>
> <ALEX>
> Actual, we would like to point to the most recent report, which is 2024:
>
> https://www.telefonica.com/en/wp-content/uploads/sites/5/2025/03/consolidated-management-report.pdf
*<Carlos>Actually, I disagree here. It is important to point to an earlier
/ the FIRST time the Telefónica Annual Report included this. We can *also*
include 2024, but can we please revert back to including 2021 as well?
Thanks!!!*
>
>
> The number we are referencing from the report (which can be found now on
> page 99) has changed. As a result, the following should be changed in the
> text:
> Original:
> For example, in its annual report, Telefónica reports that in 2021, its
> network's energy consumption per PB of data amounted to 54MWh
> [Telefonica2021].
>
> New:
> For example, in its annual report, Telefónica reports that in 2024, its
> network's energy consumption per PB of data amounted to 38 MWh
> [Telefonica2021].
>
> </ALEX>
>
> 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>
>
*<Carlos>Yes, please replace "right-placing" (there are, I believe, two
instances) with something using "correct".*
> 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> *<Carlos>Yes, I like this better. Let's replace 'tradition".*
>
>
> 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. *<Carlos>Agreed*
> </ALEX>
>
> Thank you.
>
> *<Carlos>Thank you so very much, AR!!!*
> 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
