[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.