Hi Alex, All, We updated the document and included our followup questions below.
The current files are here: https://www.rfc-editor.org/authors/rfc9845.xml https://www.rfc-editor.org/authors/rfc9845.txt https://www.rfc-editor.org/authors/rfc9845.pdf https://www.rfc-editor.org/authors/rfc9845.html Diffs of the most recent changes only: https://www.rfc-editor.org/authors/rfc9845-lastdiff.html https://www.rfc-editor.org/authors/rfc9845-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9845-auth48diff.html https://www.rfc-editor.org/authors/rfc9845-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9845-diff.html https://www.rfc-editor.org/authors/rfc9845-rfcdiff.html (side by side) Again, our comments are noted below with [rfced] and we have cut items that seem to be resolved. > >> >> • 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: [email protected], [email protected] > > [rfced] Please review the current display and let us know if this is > acceptable. We will wait to hear from Carlos on this one. > >> 13) <!--[rfced] Regarding "Definitions and Acronyms": >> >> >> 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 >> --> >> >> > >> 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> > > [rfced] We did not remove SNIC per Carlos’s preference. Please let us know > if changes are needed. > > <ALEX-2> Right now, the only place where SNIC occurs is in the acronyms, > which seems odd to me. In the interest of not adding to the alphabet soup, > since there is only one time is used, it seems to me that just using Smart > NIC (without adding SNIC ito the list of acronyms) may be preferable, but I > will be go with whatevery your recommendation. > </ALEX-2> [rfced] Our preference is to remove it, since it is not used in this document. We removed SNIC and changed “SmartNICs” to “Smart NICs” — NIC remains in the list of abbreviations. Please let us know if any updates are needed. > >> 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> > > [rfced] Updated per Alex’s reply, but we wonder if “emphasis" should be > “priority"? > > <ALEX-2> I am fine with either one, whichever you prefer. I would not want to > imply that other technology should be deprioritized, hence the preference > given to "emphasis", but both are okay. </ALEX-2> [rfced] Thanks for the explanation. Based on this “priority” sounds wrong, but giving emphasis also reads oddly. Perhaps "emphasis needs to be placed on technology that enables, … “? >> 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> > > > [rfced] Carlos replied the following to question 38 (inclusive language): > > <Carlos>Yes, please replace "right-placing" (there are, I believe, two > instances) with something using "correct”. > > We updated the text with a mix of these suggested updates. Please review and > let us know what updates are needed. > > <ALEX-2> > I don't think "right-placing" has the same meaning as "correct". It is not > that other placements are incorrect. They are less desirable and arguable > less elegant from a holistic perspective, but they are not "incorrect". So, > I don't think "correct" is the right term here that catches what we need and > this needs to be updated. > > So, I do believe "right-placing" is a more accurate term and I am not sure > why that would be considered offensive by anyone. That said, if you want to > replace it, fine, but we need a better alternative. Perhaps "Smart-placing" > (I have never seen this used - but the meaning is clear, even if not an > established term)? > > </ALEX-2> [rfced] Please discuss amongst the authors and let us know how/if “right-placing” should be updated. We suggest an update for clarity, as we do not easily find a definition for this term. A browser search for “right-placing” is not helpful; a search for “right-placing functionality” leads to an AI definition that seems to apply, but the only actual hits are for this document. Perhaps it is an area-specific term or an emerging term. We wonder about updating the text to something like “there are opportunities to identify the most suitable location for functionality in the network…”. > >> 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/conso >> lidated-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> > > [rfced] Please let us know the outcome of this discussion. > > <ALEX-2> Carlos and I have had multiple iterations over email; the latest > proposal as it stands is as follows. Carlos has not yet confirmed his > acceptance but not sent a counterproposal either so I am guessing we are > getting close. Perhaps we can incorporate it for now, and Carlos please let > Sandy know if you want a further change and/or if we need more time to > resolve. So, FWIW, this is where things stand: > > We would like to actually replace the orginal reference with the most current > one: [Telefonica2024] Telefonica, "Telefonica Consolidated Annual Report > 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, we would like to also update the text that > follows accordingly. We believe that there is value in comparing this most > current number which numbers that were reported earlier all the way back to > 2015 in the 2020 version of the report, which we would therefore like to > reference as well (in addition to the 2024 version). The reference for this > is as follows: > > [Telefonica2020] Telefonica, "Telefonica Consolidated Annual Report 2020", > https://www.telefonica.com/en/shareholders-investors/financial-reports/historical-archive-annual-reports/2020/ > > > With this, the following should be changed in the text: > > Current: > For example, in its annual report, Telefónica reports that in 2021, its > network's energy consumption per petabyte (PB) of data amounted to 54 > megawatt-hours (MWh) <xref target="Telefonica2021"/>. This rate has been > dramatically decreasing (by a factor of seven over six years), although gains > in efficiency are being offset by simultaneous growth in data volume. The > same report states that an important corporate goal is continuing on that > trajectory and aggressively reducing overall carbon emissions further. > > 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 > [Telefonica2024]. This rate has been dramatically improving from values that > were reported for earlier years, for example 115MWh/PB in 2019 or 400 MWh/PB > in 2015 [Telefonica 2020]. While portions of the gains in efficiency are > being offset by simultaneous growth in data volume, Telefónica states that an > important corporate goal is continuing on that trajectory and aggressively > reducing overall greenhouse gas emissions further. > > One question regarding the references. The annual reports are published > early in the following year, i.e. the 2024 report is actually published in > 2025. However, it is probably less confusing to use (e.g.) > "[Telefonica2024]" instead of "[Telefonica2025]". > </ALEX-2> [rfced] We have updated the text as described above for now. We await further guidance or confirmation that the current text is agreeable. "[Telefonica2024]" instead of "[Telefonica2025]” — we updated to [Telefonica2024], as it makes sense to us. However, we’re looking at general guidance on this and will circle back as needed. Thanks, Sandy Ginoza RFC Production Center > -----Original Message----- > From: Alexander Clemm <[email protected]> > Sent: Monday, August 25, 2025 11:10 PM > To: 'Sandy Ginoza' <[email protected]>; 'Carlos Pignataro' > <[email protected]> > Cc: 'Alexander Clemm' <[email protected]>; 'RFC Editor' > <[email protected]>; '[email protected]' <[email protected]>; > '[email protected]' <[email protected]>; > '[email protected]' <[email protected]>; '[email protected]' > <[email protected]>; '[email protected]' <[email protected]>; > '[email protected]' <[email protected]>; > '[email protected]' <[email protected]> > Subject: RE: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your > review > > Hi Sandy, > thank you for your update! Carlos and I are still in the process of > discussing the response to item #35 and may send you another update for that > section once we receive your updated file. Please note that I will be > traveling from this Friday (Aug 29) through Tuesday (Sep 9) so it would be > great if you could ideally send an updated file by EOB Wednesday that will > allow me to turn it around prior to my departure. > Thank you and kind regards > --- Alex > > -----Original Message----- > From: Sandy Ginoza <[email protected]> > Sent: Monday, August 25, 2025 7:39 PM > To: Carlos Pignataro <[email protected]> > Cc: Alexander Clemm <[email protected]>; Alexander Clemm <[email protected]>; RFC > Editor <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Re: AUTH48: RFC-to-be 9845 <draft-irtf-nmrg-green-ps-06> for your > review > > Greetings all, > > Thank you for your replies — we are working on an updated file to share with > you. In the meantime, here’s some info about whether this is the first > document about green/sustainable networking. > >> @RFC Editor , first, please find three questions/comments: >> • Could you please confirm that this is the first RFC being published >> about green/sustainable networking? > > A grep for “green” and “sustainability” included the following: > > RFC 9657 (Time-Variant Routing (TVR) Use Cases) mentions green computing. > https://www.rfc-editor.org/rfc/rfc9657.html > > RFC 9307 (Report from the IAB Workshop on Analyzing IETF Data (AID) 2021) has > a section on Environmental Sustainability. > https://www.rfc-editor.org/rfc/rfc9307.html#section-2.5 > > RFC 9547 (Report from the IAB Workshop on Environmental Impact of Internet > Applications and Systems, 2022) talks about sustainability. > https://www.rfc-editor.org/rfc/rfc9547.html > > This is not an exhaustive list, but these RFCs seemed the most relevant. > > Thanks, > Sandy Ginoza > RFC Production Center > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
