[DNSOP] Re: I-D Action: draft-ietf-dnsop-delext-08.txt
Petr Špaček <[email protected]> Thu, 9 Jul 2026 12:17:15 +0200
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
On 07. 07. 26 17:35, [email protected] wrote: > There is not one single approach followed currently in the IETF for tagging documents with updates. There are individual proposals out there (e.g., draft-kuehlewind-rswg-updates-tag), but discussing such proposals is not relevant to this list. > > Now for the specific draft, are there any specific parts/text in the RFCs you listed that are ** modified ** by this document? > > Please note that this document indirectly updates some of these RFCs as it updates rfc6895, which itself updates: > > * rfc1183, which updates 1035/1034. > * rfc2845, which updates 1035 The current draft does not have OLD/NEW blocks of text, but it in fact does update behavior described by 1034/1035, 2136, 4033/4034/4035, 5155, 6672, and 6840 at very least. I mean - delext draft modifies basic rules for DNS auths, resolvers, and anything doing DNSSEC, so semantically all these were updated. As an implementer/reader of the RFC stream, I very much _expect_ fundamental changes to protocol to be 'linked' via Updates tag. If you say there are no hard rules I would err to the side of adding all these to Updates field. I find it safer as it will alert readers (to the extend possible) that the old documents were affected. RFC 6895 is titled '(DNS) IANA Considerations'. I find that inadequate as a (very indirect) method to alert reader that ground-breaking delext document updates all of RFCs mentioned the above. As an implementer I would not even read it - how numeric values are assigned when protocol is under development is irrelevant to implementation. Petr Špaček >> -----Message d'origine----- >> De : Petr Špaček <[email protected]> >> Envoyé : mardi 7 juillet 2026 16:50 >> À : [email protected]; Roy Arends <[email protected]> >> Cc : Paul Hoffman <[email protected]> >> Objet : [DNSOP] Re: I-D Action: draft-ietf-dnsop-delext-08.txt >> >> >> On 06. 07. 26 20:41, [email protected] wrote: >>> Internet-Draft draft-ietf-dnsop-delext-08.txt is now available. >> It is >>> a work item of the Domain Name System Operations (DNSOP) WG of >> the IETF. >>> >>> Title: DNS Protocol Modifications for Delegation >> Extensions >>> Authors: Roy Arends >>> Peter van Dijk >>> Petr Špaček >>> Name: draft-ietf-dnsop-delext-08.txt >>> Pages: 17 >>> Dates: 2026-07-06 >>> >>> 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. >> I don't know what's the exact policy for this. >> >> Given this document standardizes new referral semantics for auths >> and resolvers I guess it should Update RFC 1034/1035? >> >> New rules for signing and validation probably warrant Updates: >> 4033/4034/4035 too. >> >> I wonder if that's enough or if it should list RFC 5155 - it >> affects opt-out rules, but in any case, the validation >> clarification in RFC 6840 section 4.1 is effectively also updated >> by introduction of the new authoritative types on the parent side >> of zone cut. >> >> If anyone has pointers to process documents about this, please >> follow them and provide your opinions. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]