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
