Hi Petr,

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

Cheers,
Med

> -----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.
> 
> --
> Petr Špaček
> 
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
____________________________________________________________________________________________________________
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]

Reply via email to