Hi, Sandy, One more follow-up email, inline, with responses marked as “[CMP]"
> On Aug 28, 2025, at 2:13 AM, Sandy Ginoza <[email protected]> > wrote: > > 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. > [CMP] Thanks, I replied in the other email with a different suggestion. > >> >>> 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. > [CMP] Removing is OK. > >> >>> 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, … “? [CMP] “placing emphasis” is the best alternative. Thank you for suggesting it! Please use “emphasis needs to be placed on …” > > > >>> 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…”. > [CMP] I strongly prefer not to use ‘right-placing’ — makes me think of left-placing :-) [CMP] "there are opportunities to identify the most suitable location for functionality in the network” is the best one yet. [CMP] But we can discuss and re-confirm. > > >> >>> 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. [CMP] Still discussing and will confirm ASAP. Thanks! Carlos. > > "[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]
