[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]