Hi Huahong,
Thank you for proposing this draft.
Conceptual comments:
- Overall, the design closely follows that of the SVCB record (RFC 9460).
Despite the striking similarity, you draft doesn't mention it.
- As the SVCB record is extensible, it seems to me that a better approach would
be to register the EEPARAMS from your draft as additional SVCB Service
Parameter Keys in the relevant registry
(https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml).
- The proposal also overlaps in scope with
draft-gakiwate-dnsop-svcb-bg-priority-parameter. You may want to reach out to
the authors of this draft to check for synergies or the possibility of merging.
Other comments:
Section 1:
* The "EE" ("Energy Efficiency") record type is defined that can be
applied directly and efficiently to a wide range of services. The
information helps make connectivity decisions with low carbon
emissions by using more renewable energy source-operated servers.
The question of server energy efficiency seems unrelated to the share of renewable
energy. If renewables should be considered, then it might be better to choose a term
different from "Energy Efficiency".
Section 2.1:
- No need to show the generic record format, i.e., you can drop Figure 1.
Section 2.3.4:
- Those are format specifications, so can't use SHALL (which would allow
exceptions)
- I'm not sure about the difference in meaning between "eei" and "pue"
- "The presentation value SHALL be 4 bits in length" -- presentation format is
always ASCII, so can't be 4 bit. Do you mean wire format? Also, why use 4 bits for a
5-valued parameter?
Section 5.1:
When replying to an EE query, authoritative DNS servers SHOULD return
A, AAAA, and EE records in the Additional section for any ENAME that
is in the zone.
- For EE queries, the EE record is already in the Answer Section, so it
shouldn't go into the Additional Section
- Adding A/AAAA/EE records of all ENAMEs in the whole zone is not a good idea,
as it may lead to very large responses (which is undesirable) and further leaks
unrelated names (which is also undesirable). In addition, the ENAME is part of
the EE rdata and typically not indexed, i.e., its hard to compile such a
response.
Best,
Peter
On 2/12/26 08:06, 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
-----------------------------------------------
朱华虹 博士
中国电信股份有限公司研究院（广州园区）
手机：13316097206
-----------------------------------------------
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
