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

zhuhh11 <zhuhh11@chinatelecom.cn> Mon, 20 April 2026 12:49 UTC

Return-Path: <zhuhh11@chinatelecom.cn>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 397E1DF914E6 for <dnsop@mail2.ietf.org>; Mon, 20 Apr 2026 05:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776689389; bh=1ksulAMrsL0BWuwkYyK4tEb6hm6mVEQfu+i2Wohu15M=; h=From:To:Subject:Date; b=YtPEq3TK1M3naHGL7lgxwDjSbqR/YaMGQmtz37u4sp5aym6g+TglkWs5sfnVRDY7D J+mWjuCeAUjx49fOwmerieDKjlUJqr88p5PzpYfkhFw+sCUOa9bi1cCsty86Ib0ibO nCTnkTpU1l5PAYYspS1YoJslilhzHdD/1+OFgf1k=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MYdtpgFa9uU for <dnsop@mail2.ietf.org>; Mon, 20 Apr 2026 05:49:46 -0700 (PDT)
Received: from smtph3-02.21cn.com (smtph3-02.21cn.com [150.223.194.82]) by mail2.ietf.org (Postfix) with ESMTP id BF7E1DF91407 for <dnsop@ietf.org>; Mon, 20 Apr 2026 05:49:26 -0700 (PDT)
HMM_SOURCE_IP: 172.27.0.98:1.1247442609
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-61.144.66.66 (unknown [172.27.0.98]) by smtph3-02.21cn.com (HERMES) with SMTP id 35A02C00D7E3 for <dnsop@ietf.org>; Mon, 20 Apr 2026 20:49:13 +0800 (CST)
X-189-SAVE-TO-SEND: 44031128@chinatelecom.cn
Received: from ([61.144.66.66]) by gateway-ssl-dep-548b9f977f-b9k8t with ESMTP id 36dea5ed10fa4a579dd71a2e100494eb for dnsop@ietf.org; Mon, 20 Apr 2026 20:49:16 CST
X-Transaction-ID: 36dea5ed10fa4a579dd71a2e100494eb
X-Real-From: zhuhh11@chinatelecom.cn
X-Receive-IP: 61.144.66.66
X-MEDUSA-Status: 0
Sender: zhuhh11@chinatelecom.cn
From: zhuhh11 <zhuhh11@chinatelecom.cn>
To: dnsop@ietf.org
Date: Mon, 20 Apr 2026 20:49:13 +0800
Message-ID: <000001dcd0c4$17f398c0$47daca40$@chinatelecom.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01DCD107.261949C0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdzQw0wNAb0LKJSNT26R6a/+K07yoA==
Content-Language: zh-cn
Message-ID-Hash: 4NVZCHBORTOUZYF2TZBZZM5BNK3HXKMH
X-Message-ID-Hash: 4NVZCHBORTOUZYF2TZBZZM5BNK3HXKMH
X-MailFrom: zhuhh11@chinatelecom.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Call for adoption: draft-zhu-dnsop-de-eeas-02
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/znm4RNX206XII_yXcUWDj-WjdVw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

 

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.