I’ve submitted draft-ietf-dnsop-delext-08: https://datatracker.ietf.org/doc/draft-ietf-dnsop-delext/08/
Please note the following: Version 03 was reviewed during DNSOP WG last call, all comments have been addressed to Version 04. Substantial comments by Mohamed Boucadair have been addressed in 07 (and is currently in IETF last call) (Versions 05, 06 and 07 were rapid submission, all addressing Med’s comments, which can be found here: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-dnsop-delext-03-rev%20Med.pdf ) In addition, a call with the authors of draft-ietf-deleg and Paul Hoffman, on July 2nd lead to the following changes: 1) I was kindly reminded that it was not appropriate to re-specify existent behaviour of resolvers that are not aware of deleg/delext, which led to the following change: The normative language in the second paragraph of sections 4.1 and 4.2 (about DE=0) now contain notes and informative language. This was quite important, as the original normative specification language in the second paragraph of section 4.2 was factually incorrect. 2) I was requested to change a MAY into a MUST in the last paragraph of section 5.2, which now reads: "When the referral contains no Delegation Type RRsets, the resolver MUST use NS records. Note that DNSSEC can prove the presence and absence of Delegation Types at a delegation”. (This was discussed in the DELEG WG, though I misinterpreted it) 3) I removed the overly restrictive use of the Private Use Range. What is done in private is not a concern. 4) I’ve made the Delegation Types CLASS independent. 5) I’ve blatantly copied the Acknowledgments section from draft-ietf-deleg, as delext is an abstraction of the work done by the many contributors to deleg. In addition to the above, I’ve made the following two changes: 6) I replaced all instance of the term “Legacy” with “non-Delegation-Extension-aware”, as “Legacy” is often interpreted as outdated, and implies that the draft has obsoleted something, which is not the case. 7) I’ve added an Extended DNS Error INFO-CODE request to the IANA section. I was reminded that recommending sending an extended DNS error, without specifying one is incomplete. The existing set of extended DNS error INFO-CODEs are not applicable. Warmly, Roy Arends > On 1 Jul 2026, at 18:09, The IESG <[email protected]> wrote: > > > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'DNS Protocol Modifications f= > or > Delegation Extensions' > <draft-ietf-dnsop-delext-07.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2026-07-15. Exceptionally, comments may > be sent to [email protected] instead. In either case, please retain the beginni= > ng > of the Subject line to allow automated sorting. > > Abstract > > > The Domain Name System (DNS) protocol permits Delegation Signer (DS) > records at delegation points. This document specifies modifications > to the DNS protocol to permit a range of resource record types at > delegation points. These modifications are designed to maintain > compatibility with existing DNS resolution mechanisms and provide a > secure method for processing these records at delegation points. > > This document updates RFC 6895. > > > > > The file can be obtained via > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dns= > op-delext/__;!!PtGJab4!5AdymoTzLIW2iM5MK2-KRQtyP598vev2O75ueT6DGvro1RqJZJQf= > 7zqGxFYfZq2wDZC8_DFlms9lGC4LE7cgUkyi0-CWBP0$ [datatracker[.]ietf[.]org] > > > > No IPR declarations have been submitted directly on this I-D. > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
