Hi Petr, > 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 wasn't looking necessarily for changes using OLD/NEW, but a clear statement of how to interpret each of the (candidate) updates you had in mind. I'm puzzled by the list you provided as the doc does not even have 4035, 5155, 6672, 6840 as normative references. 1034/1035 are not listed as well, but I'm not putting these under the same category as the other because these can be "safely assumed to be known to practitioners" [1]. Cheers, Med [1] https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/ > -----Message d'origine----- > De : Petr Špaček <[email protected]> > Envoyé : jeudi 9 juillet 2026 12:17 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected]; Roy Arends <[email protected]> > Cc : Paul Hoffman <[email protected]> > Objet : Re: [DNSOP] Re: I-D Action: draft-ietf-dnsop-delext-08.txt > > > 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. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
