Hi Scott,
Thank you for elaborating. -- I believe your suggestion fits better under
Section 4.2.1 (which discusses interpretation of EPP specs), not 4.2.2 (which
explains conceptual reasons behind the recommendation, irrespective of EPP).
I've merged the two text suggestions you gave in this thread and adapted for
flow, and added the result as a new paragraph at the end of Section 4.2.1:
NEW
DS automation by the registry further is consistent with [RFC5731],
Section 2.3, which explicitly notes that an EPP server (registry) may
override status values set by an EPP client (registrar), subject to
local server policies. The risk that DS changes from registry-side
DS automation might go unnoticed by the registrar is mitigated by
sending change notifications to the registrar; see Recommendation 4
of Section 3.
The change is committed here.
https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/ba8a55546451b07bd6ed3b326e9632ee135305c2
This was the last open issue from WGLC; I'll submit a new revision shortly.
Best,
Peter
On 2/5/26 13:19, Hollenbeck, Scott wrote:
-----Original Message-----
From: Peter Thomassen <[email protected]>
Sent: Sunday, February 1, 2026 3:20 PM
To: Hollenbeck, Scott <[email protected]>; [email protected];
[email protected]; [email protected]; draft-ietf-dnsop-ds-
[email protected]
Subject: [EXTERNAL] Re: [DNSOP] Re: WG Last Call: draft-ietf-dnsop-ds-
automation-02 (Ends 2026-01-30)
Caution: This email originated from outside the organization. Do not click links
or open attachments unless you recognize the sender and know the content is
safe.
Hi Scott,
Thank you for your suggestion. Before I include it, I'd like to fully
understand it.
You pointed out that
a) "A server MAY alter or override status values set by a client, subject to
local
server policies" (RFC 5731),
b) automated DNSSEC delegation trust maintenance may well be part of a
server policy.
However, DNSSEC delegation trust maintenance does not alter EPP statuses.
Rather, the recommendation (with which you said you agree) is to perform DS
automation (that is, change DS RRsets, not EPP statuses) even when
clientUpdateProhibited or serverUpdateProhibited is set.
So, while I think both (a) and (b) are true, I'm not sure how (a) is relevant
for
DS automation.
I might have missed your point -- can you please elaborate?
[SAH] Section 4 of the draft discusses registration locks. There are client-set status
values, such as clientUpdateProhibited, that could, under most circumstances, prevent a
DNS service provider from updating DNSSEC information if that particular status value is
set. I'm merely pointing out that RFC 5731 specifically allows the server operator to
override that restriction if the server implements a policy that supports DS automation.
Section 4.2.2 of the draft describes the rationale for overriding an "update
prohibited" status, but it doesn't mention the fact the 5731 makes it explicitly
possible. I think it would be helpful to add a sentence in 4.2.2 to acknowledge that
ability. Perhaps something like this at the end of the first paragraph in 4.2.2:
OLD
Such changes entail updating the delegation's DS records.
NEW
Such changes entail updating the delegation's DS records. These changes are consistent
with the guidance provided in RFC 5731, which explicitly states that "A server MAY
alter or override status values set by a client, subject to local server policies"
[RFC5731].
Scott
--
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]
