[DNSOP] Re: Call for adoption: draft-zhu-dnsop-de-eeas-02

[Benno Overeinder <[e-mail]>]

Dear Huahong,

According to the process, the DNSOP chairs issue a call for adoption.

Before doing so, we would like to see some discussion take place on the 
mailing list and/or during an IETF DNSOP WG meeting to confirm that 
there is sufficient interest in the topic within the working group.

So far, we have not seen substantive discussion of the draft on the 
mailing list.  And there was unfortunately no time available at IETF 125 
to present the draft (as noted in the agenda "time permitted").

I also wonder whether DNSOP is the most appropriate venue for this work, 
as the draft introduces a mechanism on top of DNS for energy 
(efficiency) management.  You may want to consider reaching out to the 
GREEN WG chairs as well for their perspective.

Best regards,

-- Benno
for DNSOP chairs


On 20/04/2026 14:49, zhuhh11 wrote:
> Dear dnsop WG,
> 
> Please review the draft, and give us some advice.
> 
> Full draft:https://datatracker.ietf.org/doc/draft-zhu-dnsop-de-eeas/
> 
> I would appreciate any further review and feedback from the group.
> 
> Best regards,
> 
> Huahong
> 
> Our thinking on this draft is as follows:
> 
> 1、We do not have extensive experience in writing a draft. So there may be
> 
> some wrongs about format and content and We will revise them according  the
> 
> guidance from the experts. We also hope that interested experts can
> 
> collaborate with us to this work.
> 
> 2、We have considered the SVCB parameters defined in RFC 9460, but still
> 
> prefer to use an independent RR for the following reasons:
> 
> a\SVCB includes parameters such as protocol information, which are IT
> 
> software-related negotiation items essential for connection setup. In
> 
> contrast, we regard energy information as infrastructure information.
> 
> b\With the development of AI, energy demand has grown significantly, and
> 
> energy types and deployments have become more diverse. For example,
> 
> satellites are equipped with photovoltaic panels and also host MEC systems.
> 
> These scenarios require coordinated evolution and consideration of networks
> 
> and data center infrastructure.
> 
> c\In addition, environmental advocates have raised relevant requirements.
> 
> Therefore, it is optimal for terminals to support Energy-as-a-Service
> 
> options.
> 
> d\From the perspective of network operators, we hope this RR can enable
> 
> coordination among terminals, networks, and services, rather than acting
> 
> merely as a simple pipe.
> 
> d\As services evolve, we believe more operators will participate in building
> 
> the energy Internet, in which DNS plays an important role.
> 
> e\For these reasons, we propose using an independent parameter that can be
> 
> requested on demand. This will also reduce issues related to excessive
> 
> information volume caused by carrying it together with protocol and other
> 
> parameters.
> 
> 3、We intend for the term “Energy Efficiency” in the parameter to also
> 
> carry energy type information, especially regarding renewable energy.
> 
> Environmental advocates show a clear preference for renewable energy
> 
> sources. In our view, energy efficiency should include information on
> 
> whether the energy is renewable. If the current definition is not
> 
> sufficiently accurate, we will consider revising it in subsequent versions.
> 
> 4、PUE refers to the overall power usage effectiveness of the data center.
> 
> A higher value indicates greater energy loss. For instance, liquid cooling
> 
> typically yields a lower PUE than air cooling, and PUE is also closely
> 
> related to operational costs. Therefore, data centers with low PUE are
> 
> preferred.
> 
> EEI is an energy-saving performance indicator for the equipment itself; a
> 
> higher grade indicates better performance. The two metrics are distinct. Or
> 
> can be optional for the service.
> 
> 5、2.3.4”This representation” is here for wire-format extensibility.
> 
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/